PW Security and Backup privacy and data handling
PW Security and Backup is designed to provide WordPress security monitoring, login protection, file-integrity controls and manual backup tools within the website owner’s own WordPress installation and hosting environment.
The plugin does not require a PW Feed or Poyraz Web account, licence key, remote security dashboard, external malware-scanning service or cloud-backup subscription.
PW Security and Backup does not send telemetry, security results, login records, traffic records, credentials, file contents or backup archives to PW Feed, Poyraz Web or another service operated by the plugin developer.
Certain features may process and store security-related information locally. Depending on the enabled settings, this information may include IP addresses, WordPress usernames, request paths, file information, security events, scan findings and backup archives.
The website owner or administrator is responsible for determining how these features should be configured, how long locally stored information should be retained, who may access it and which disclosures are required under applicable privacy and data-protection rules.
This page explains what information the plugin may process, why it is used, where it is stored and which privacy precautions website administrators should consider.
It provides product information and practical guidance. It is not legal advice and does not automatically make a website compliant with any particular privacy law or regulatory framework.
Privacy at a glance
The following points summarise the plugin’s approach to privacy and data handling:
• The plugin’s main security operations run on the user’s own WordPress website.
• No licence key or remote user account is required.
• No telemetry is sent to PW Feed or Poyraz Web.
• Scan findings are not submitted to a remote scanning service.
• Backup archives are not uploaded to a PW Feed or Poyraz Web server.
• Live Traffic is disabled by default.
• Security records may contain IP addresses and WordPress account information.
• Manual full backups may contain the complete website database and other sensitive information.
• Email notifications use the website’s existing WordPress email system.
• Administrators control access to the plugin through WordPress permissions.
• Available traffic and log records can be reviewed and cleared by an authorised administrator.
• Backup archives are deliberately preserved when the plugin is uninstalled.
• Website owners remain responsible for privacy notices, retention decisions, access control and secure external storage.
Local security processing
PW Security and Backup performs its main operations inside the WordPress installation where it is activated.
For example, the plugin can:
• Evaluate configured login-protection rules.
• Record unsuccessful login attempts.
• Apply temporary IP bans.
• Maintain administrator-defined IP allowlists and blocklists.
• Inspect website files for suspicious code patterns.
• Calculate SHA-256 file-integrity signatures.
• Compare current files with a trusted integrity baseline.
• Store security events in local logs.
• Record a limited history of website requests when Live Traffic is enabled.
• Create manual ZIP backups containing website files and database tables.
• Compare current files with selected backup archives.
• Recover selected files from an available backup.
These operations do not require the website’s files, findings or logs to be uploaded to a remote PW Feed or Poyraz Web system.
Local processing can reduce unnecessary external data transfers, but it does not remove the administrator’s privacy and security responsibilities. Information stored in the WordPress database or hosting account must still be protected against unauthorised access.
Information the plugin does not send to PW Feed or Poyraz Web
PW Security and Backup does not send the following information to PW Feed or Poyraz Web:
• WordPress administrator usernames or passwords.
• The additional security password.
• Hosting, FTP, SFTP or database credentials.
• SMTP passwords.
• WordPress authentication cookies.
• File Scanner findings.
• File contents inspected by the scanner.
• File-integrity baselines.
• SHA-256 integrity results.
• Quarantined files.
• Login-attempt histories.
• IP allowlists or blocklists.
• Live traffic records.
• Security logs.
• Downloaded analysis reports.
• WordPress database contents.
• Customer or order information.
• Backup ZIP archives.
• Website visitor profiles.
• Product-usage telemetry.
• Advertising identifiers.
• Marketing analytics.
The plugin does not use a hidden remote dashboard that allows PW Feed or Poyraz Web to view the website’s security status.
Support representatives cannot automatically access the website, its logs, its configuration or its backup archives. If assistance is requested, the administrator must voluntarily provide the minimum non-sensitive information required to explain the problem.
Information that may be processed locally
The exact information processed by PW Security and Backup depends on which features are enabled and which events occur on the website.
Not every installation will store every category described below.
IP addresses
IP addresses may be processed in connection with:
• Failed WordPress login attempts.
• Temporary IP bans.
• Administrator-defined IP allowlists.
• Administrator-defined IP blocklists.
• Security events.
• Live Traffic records.
• Administrator login notifications.
• Suspicious request classifications.
An IP address can relate to a person, household, organisation, proxy, mobile network, content delivery network or shared internet connection. It should therefore be treated as security-related information and, where applicable, personal information.
IP-based controls should be configured carefully. A dynamic IP address may change, and an address previously used by one person may later be assigned to another person.
A reverse proxy, content delivery network or load balancer may cause WordPress to receive an intermediary server address instead of the original visitor address. Administrators should verify their hosting and proxy configuration before relying on IP information for access decisions.
Unverified forwarded-IP headers should not be trusted automatically because they may be manipulated.
WordPress account information
Security logs and login-related features may process information associated with a WordPress account, such as:
• Username.
• WordPress user identifier.
• User role.
• Login time.
• Failed-login event.
• Administrator login event.
• Related IP address.
• Security action associated with the account.
This information helps administrators investigate login activity and identify unexpected access.
Plugin access should be limited to trusted users with appropriate WordPress permissions. An administrator account should not be shared by multiple people because shared accounts make activity records more difficult to interpret.
Unused administrator accounts should be removed or downgraded when elevated access is no longer required.
Failed-login information
Failed-login protection can record unsuccessful attempts within a configured tracking period.
A record may include:
• Attempted username.
• Date and time.
• Source IP address.
• Number of failed attempts.
• Ban status.
• Ban start or expiry information.
A failed login does not automatically mean that an attack occurred. It may result from an authorised user entering an incorrect password, an outdated application, an automated bot or a deliberate access attempt.
These records should be used as security indicators and reviewed in context.
IP allowlists and blocklists
An administrator may manually add trusted addresses to an allowlist or unwanted addresses to a blocklist.
These lists are stored for the purpose of applying the configured security rules.
Before adding an address, the administrator should confirm:
• Who or what uses the address.
• Whether the address is static or dynamic.
• Whether it belongs to a proxy, hosting service or monitoring system.
• Whether blocking it could prevent authorised administration.
• Whether allowlisting it could bypass an important protective control.
Descriptions or notes added to IP records should not contain passwords, private keys or unnecessary personal information.
Additional security password
The plugin can provide an additional security-password field on the WordPress login form.
The additional password should be different from every WordPress account password and should be shared only with authorised users.
It must never be included in:
• Public support requests.
• Public screenshots.
• Unprotected notes.
• Website content.
• Source-code repositories.
• Security logs.
• Email messages sent without appropriate protection.
PWPW Security and Backup does not send the additional security password to PW Feed or Poyraz Web.
Administrators remain responsible for communicating and storing the additional password securely.
Question-and-answer verification
If question-and-answer verification is enabled, the administrator defines the verification question and accepted answer used by the login-protection process.
The question should not request unnecessary personal information.
Avoid questions based on information that is easily available through social media, company websites, public records or ordinary personal knowledge.
A security answer should be treated like a password and should not be publicly disclosed.
File Scanner information
The File Scanner examines selected WordPress areas for code patterns and file characteristics that may require investigation.
Depending on the result, the plugin may locally store information such as:
• Complete file path.
• File name.
• Reported risk level.
• Finding category.
• Finding description.
• Relevant code line or limited code context.
• File modification information.
• Administrator action.
• Ignore status.
• Administrator note.
A scanner finding does not prove that a file is malicious. Legitimate software may use functions or patterns that also appear in unsafe code.
Scanner findings may reveal technical information about the website’s directory structure, plugins, themes or custom software. Access to these findings should therefore be limited to authorised administrators.
Do not publish full private file paths or complete commercial source-code files in a public support request.
Ignored scanner findings
An authorised administrator can ignore a finding after reviewing it.
Ignoring a finding does not:
• Delete the file.
• Modify the reported code.
• Prove that the file is safe.
• Prevent the file from changing later.
• Guarantee that future versions of the file will remain legitimate.
An explanatory note should be added where available so that another administrator can understand why the item was ignored.
Ignored findings should be reviewed again after software updates, ownership changes or security incidents.
Notes should not contain passwords, access credentials or unnecessary personal information.
Quarantine information
When a file is quarantined, it is moved away from its normal active location and information about the action may be stored locally.
A quarantine record may identify:
• Original file path.
• Quarantine location.
• Date and time.
• Related finding.
• Administrator responsible for the action.
• File status.
Quarantined files may still contain sensitive or malicious content. They should not be downloaded, opened or executed on an ordinary workstation without appropriate precautions.
Quarantine is an isolation measure. It does not automatically remove every related threat or identify how the file entered the website.
Only authorised administrators should have access to quarantined material.
File-integrity information
File Integrity creates a trusted reference for selected WordPress files and directories.
The baseline may contain:
• File paths.
• File names.
• SHA-256 signatures.
• File status information.
• Baseline creation time.
• Later comparison results.
• Modified, added or deleted file records.
A SHA-256 signature is used to determine whether file content has changed. It is not a copy of the original file and cannot ordinarily be used to reconstruct the file contents.
File paths and change records can still reveal technical information about the website. They should be protected accordingly.
A baseline must be created only after the administrator has confirmed that the website is clean and trusted. Otherwise, an unauthorised file may become part of the accepted reference.
Security logs
Security logs may contain:
• Date and time.
• Event type.
• Event description.
• IP address.
• WordPress username.
• Related user identifier.
• Security action.
• Result or status.
These records help administrators understand what happened and when it occurred.
Log information may be useful for troubleshooting, incident investigation and operational security. However, retaining unnecessary records indefinitely can increase privacy risk and database size.
Administrators should choose a retention period appropriate for the website’s security needs, traffic, legal obligations and hosting capacity.
Log exports
Available security logs can be exported in CSV format.
An exported file may contain IP addresses, usernames, timestamps and descriptions of security events.
Exported CSV files should be:
• Downloaded only by authorised users.
• Stored in a protected location.
• Removed when no longer required.
• Shared only with authorised people.
• Reviewed before being attached to a support request.
• Protected during transfer.
Do not upload an unredacted log export to a public forum or place it in a publicly accessible website directory.
Deleting local WordPress records does not automatically delete copies that were previously exported or shared.
Live Traffic information
Live Traffic can record a limited history of website requests when the administrator explicitly enables it.
Live Traffic is disabled by default.
Depending on the request and plugin configuration, a traffic record may contain:
• Date and time.
• Request path.
• IP address.
• HTTP method.
• Referrer information.
• User-agent information.
• Traffic classification.
• Bot or suspicious-activity indicator.
Request paths and referrer information can sometimes contain search terms, identifiers or other information supplied by a visitor or another website.
Administrators should therefore enable Live Traffic only when its security or diagnostic value justifies the additional local processing.
Live Traffic and database growth
Traffic recording can increase WordPress database activity and storage use, particularly on websites with many visitors, automated bots or repeated unwanted requests.
Before enabling Live Traffic, consider:
• Why the information is needed.
• Who will review it.
• How long it should be retained.
• Whether the website receives high traffic.
• Whether request paths may contain personal information.
• Whether another server or analytics log already provides the same information.
• Which privacy disclosures may be required.
When the records are no longer needed, they can be cleared from the plugin screen.
Before clearing information connected to an active security investigation, determine whether an authorised and protected copy should be preserved.
Traffic classifications
The plugin may classify a request as normal, bot-related or potentially suspicious according to available request characteristics.
A classification is a security indicator. It is not proof that a particular person attempted an attack.
A legitimate search engine, uptime service, integration, accessibility tool or unusual visitor request may sometimes appear suspicious.
Administrators should examine the available context before placing an IP address on a permanent blocklist or taking another consequential action.
Manual full backups
The manual full-backup feature can create a ZIP archive containing WordPress files and database tables.
A complete backup may contain highly sensitive information, including:
• WordPress configuration values.
• Database connection information.
• Password hashes.
• Usernames and email addresses.
• Website content.
• Form submissions.
• Customer records.
• WooCommerce orders.
• Billing and shipping addresses.
• Plugin and theme settings.
• Security logs.
• IP addresses.
• Private uploaded files.
• Authentication or integration values stored by WordPress or another plugin.
A backup archive must therefore be treated as confidential security and recovery data.
PW Security and Backup does not upload these archives to PW Feed or Poyraz Web.
Backup storage location
Backup archives are stored in a randomly named, protected directory below the WordPress uploads directory.
The protected and randomly named location helps reduce ordinary public exposure. It does not make a backup risk-free.
A backup could still be exposed if:
• Hosting permissions are incorrect.
• Server-protection rules are unsupported or removed.
• Another plugin reveals the file location.
• The hosting account is compromised.
• An administrator creates a public download link.
• A backup is copied into a public directory.
• Server configuration allows unintended access.
Administrators should verify that backup URLs cannot be accessed by unauthorised visitors.
External backup copies
An important backup should not exist only on the same server as the live website.
The backup should be downloaded and stored in a secure external location because a local copy may become unavailable during:
• Hosting failure.
• Storage failure.
• Account suspension.
• Destructive malware activity.
• Unauthorised server access.
• Accidental deletion.
• Website corruption.
• Domain or control-panel access problems.
External backup storage may involve another provider. That provider’s security, location, access controls, retention rules and privacy terms should be reviewed separately.
PW Security and Backup does not automatically select or control the external storage service used by the administrator.
Backup downloads
Downloading a backup transfers sensitive website information from the hosting server to the administrator’s device or selected storage location.
Before downloading an archive:
• Use a trusted device.
• Use a secure network.
• Confirm that HTTPS is active.
• Verify the destination folder.
• Avoid shared or public computers.
• Do not store the archive in an automatically shared folder unless intended.
• Protect the device against unauthorised access.
• Remove unnecessary copies after confirming that a verified backup remains available.
A backup should never be sent through an unsecured public link or attached to an ordinary public support request.
Backup deletion
Backup archives can be deleted from the Server Backups screen.
Deletion is permanent. Before removing an archive, confirm that:
• It is no longer required.
• It is not the only usable recovery copy.
• Another external copy exists where appropriate.
• The replacement backup has been verified.
• No active security investigation depends on it.
Deleting a backup from the WordPress server does not remove copies already downloaded, transferred or stored elsewhere.
Plugin uninstall and backup retention
Uninstalling PW Security and Backup does not automatically delete backup ZIP archives.
This behaviour is intentional because removing a plugin should not silently destroy important recovery data.
After uninstalling the plugin, the website administrator remains responsible for:
• Identifying preserved archives.
• Downloading archives that must be retained.
• Removing archives that are no longer required.
• Confirming that the storage directory remains protected.
• Managing external copies.
• Following applicable retention requirements.
Do not assume that uninstalling the plugin removes every backup or exported record previously created by an administrator.
Selected-file recovery
Selected-file recovery compares the current website with an available backup and allows an authorised administrator to recover individual files.
The current administration interface does not provide automatic one-click restoration of the complete website and database.
Before recovering a selected file, the administrator should verify:
• The identity of the backup.
• The date of the archive.
• The original website associated with the backup.
• The file version.
• Compatibility with the current WordPress installation.
• Whether a current recovery copy exists.
• Whether the action may affect personal or business data.
Recovery actions may replace current information with older information. An incorrect recovery decision can create compatibility, security or operational problems.
Email notifications
PW Security and Backup can use the WordPress email system to send enabled security notifications.
Depending on the selected settings, a notification may relate to:
• File changes.
• Administrator logins.
• IP bans.
• Other supported security events.
Although the plugin does not send telemetry or security results to PW Feed or Poyraz Web, an enabled email notification is transmitted through the email system configured by the website administrator.
This system may involve:
• The hosting provider’s mail server.
• An SMTP provider.
• A transactional email service.
• The recipient’s email provider.
• An email-delivery plugin.
The privacy and security terms of those systems are separate from PW Security and Backup.
Administrators should avoid placing unnecessary sensitive information in notification settings and should protect the configured recipient account.
Notification recipients
Security notifications should be sent only to an address controlled by an authorised person or team.
Before saving a recipient address:
• Confirm that the address is correct.
• Confirm that the mailbox is protected.
• Limit mailbox access.
• Use multi-factor authentication where available.
• Remove former staff members from shared access.
• Check that forwarded messages do not reach unauthorised recipients.
• Review retention rules for security emails.
A mistyped email address may disclose security information to the wrong recipient.
Scheduled checks
The plugin can schedule supported health and file-integrity checks.
Available intervals may include:
• Every 6 hours.
• Every 12 hours.
• Every 48 hours.
• Weekly.
• Every two weeks.
• Monthly.
Scheduled checks process the information required to complete the configured local security operation.
They do not create automatic full backup archives in the current version.
Scheduled tasks normally depend on WordPress WP-Cron. If a hosting-level cron is used, the hosting provider may process ordinary technical request information according to its own systems and policies.
Security Analysis information
The Security Analysis screen combines available plugin information into a practical assessment.
It may display:
• Security score.
• Risk score.
• Priority risk.
• Overall assessment.
• Recommended actions.
• Analysis metrics.
• Risk records.
• Recent log information.
The score and report are generated from available website information. They are not sent to PW Feed or Poyraz Web.
A report can be downloaded in TXT format for authorised review. The downloaded report may contain technical details about the website’s security configuration and should be reviewed before it is shared.
Data access inside WordPress
Access to PW Security and Backup should be limited to trusted WordPress administrators with the required permissions.
Administrators may be able to view:
• Login attempts.
• IP bans.
• Allowlist and blocklist entries.
• Scanner findings.
• Ignored findings.
• Quarantine records.
• File-integrity differences.
• Traffic records.
• Security logs.
• Backup archives.
• Analysis information.
A person who can access these areas may also be able to download, export, delete or act on security-related information.
WordPress accounts should use strong unique passwords. Multi-factor authentication should be enabled through a compatible solution where available.
Least-privilege access
Every user should receive only the level of WordPress access required for their role.
To reduce unnecessary exposure:
• Do not give administrator access to ordinary editors or contributors.
• Do not share one administrator account among multiple people.
• Remove inactive administrator accounts.
• Review agency and developer access after work is completed.
• Protect emergency accounts.
• Review account activity regularly.
• Change credentials after a suspected compromise.
• Keep recovery information in a secure location.
Limiting administrator access protects both the website and the security information stored by the plugin.
Retention responsibilities
PW Security and Backup provides operational controls for certain records, but it cannot determine the correct retention period for every website.
Appropriate retention depends on factors such as:
• Website type.
• Security risk.
• Traffic volume.
• Hosting capacity.
• Contractual obligations.
• Active investigations.
• Applicable privacy requirements.
• Business record-keeping needs.
• Whether the website processes customer information.
Administrators should avoid retaining security-related information indefinitely without a defined reason.
A practical retention process includes:
- Identifying which records are stored.
- Defining why each record is needed.
- Selecting an appropriate retention period.
- Restricting access.
- Reviewing records periodically.
- Deleting information that is no longer required.
- Managing exported and downloaded copies separately.
Clearing records
Available Live Traffic records can be cleared through the plugin interface.
Security-log retention can be configured according to the website’s operational requirements.
Some information may also exist in:
• WordPress database backups.
• Hosting backups.
• Exported CSV files.
• Downloaded TXT reports.
• Email notifications.
• Server logs.
• External storage.
• Administrator devices.
Removing a record from the current WordPress database does not automatically remove every copy stored elsewhere.
Administrators should consider the complete information lifecycle when responding to an access, correction or deletion request.
Website backups and deletion requests
A person’s information may remain inside a historical website backup even after it has been removed from the live WordPress database.
Immediate modification of every backup may damage archive integrity or make disaster recovery impossible.
The website owner should establish a documented process for handling information contained in backups, including:
• Limiting backup access.
• Defining retention periods.
• Preventing ordinary use of outdated personal information.
• Removing expired archives.
• Applying required changes if a backup is restored.
• Recording restoration dates.
• Reviewing the restored database before the website returns to normal operation.
The appropriate process depends on applicable requirements and the organisation’s backup policy.
WooCommerce websites
A WooCommerce backup can contain more sensitive information than an ordinary public website.
It may include:
• Customer names.
• Email addresses.
• Telephone numbers.
• Billing addresses.
• Shipping addresses.
• Order details.
• Product information.
• Customer notes.
• Account records.
• Tax-related information.
• Payment-related references stored by WooCommerce or another extension.
PW Security and Backup does not send this information to PW Feed or Poyraz Web.
However, a manual full-backup archive may contain the WordPress database in which this information is stored.
WooCommerce backup access should be particularly restricted. Restoring an older database can also remove or overwrite orders created after the backup date.
Complete WooCommerce database restoration should be planned carefully and may require hosting tools or professional assistance.
Hosting providers and other services
PW Security and Backup operates within an existing technical environment.
Even though the plugin does not transmit telemetry to its developer, website information may still be processed by services selected by the website owner, including:
• Web-hosting providers.
• Database servers.
• Content delivery networks.
• Reverse proxies.
• Firewall services.
• DNS providers.
• SMTP and email providers.
• External backup-storage providers.
• Website-monitoring services.
• Other WordPress plugins.
• Analytics services independently installed on the website.
These services are not controlled by PW Security and Backup.
Website administrators should review each provider separately and should not assume that installing this plugin changes another provider’s privacy practices.
Support requests
PW Feed or Poyraz Web cannot automatically view locally stored plugin information.
When requesting support, provide only the minimum information required to understand the problem.
Suitable non-sensitive information may include:
• WordPress version.
• PHP version.
• PW Security and Backup version.
• Relevant administration screen.
• Exact error message.
• Operation performed before the problem occurred.
• Whether the problem can be reproduced.
• Redacted screenshot.
Never include:
• WordPress passwords.
• The additional security password.
• Hosting credentials.
• FTP or SFTP credentials.
• Database credentials.
• SMTP passwords.
• Authentication cookies.
• Private keys.
• Secret tokens.
• Complete backup archives.
• Complete wp-config.php contents.
• Unredacted customer information.
• Unredacted security logs.
• Private source code unrelated to the specific problem.
Before sharing a screenshot, check the complete image for visible URLs, usernames, IP addresses, email addresses, file paths, access tokens and browser information.
Public support forums
Information posted in a public support forum may be indexed by search engines, copied by other services and retained after the original post is edited.
Use a general description first. Share limited technical details only when required.
Do not publish a secret custom login address unless disclosure is necessary and the address will be changed afterward.
If a support representative requests sensitive access, confirm the identity of the recipient, the reason for access, the permitted scope and the method used to protect the information.
Temporary access should be removed when the support process is complete.
Security incidents
If a website is compromised, security records may be relevant to an investigation.
During an active incident:
- Restrict unauthorised access.
- Preserve relevant evidence.
- Avoid uncontrolled deletion.
- Record important dates and actions.
- Change credentials from a trusted device.
- Review administrator accounts.
- Contact the hosting provider.
- Protect customer and user information.
- Determine whether professional assistance is required.
- Follow applicable notification and incident-response obligations.
PW Security and Backup provides practical evidence and recovery tools, but it does not automatically determine whether a legal data breach has occurred.
A serious incident may require server-level investigation and qualified professional assistance.
Data security precautions
Administrators should protect locally stored plugin information by:
• Keeping WordPress current.
• Keeping plugins and themes current.
• Using supported PHP versions.
• Using HTTPS.
• Using strong unique passwords.
• Enabling multi-factor authentication where available.
• Limiting administrator access.
• Protecting hosting and database accounts.
• Reviewing file permissions.
• Securing backup directories.
• Downloading important backups to protected external storage.
• Deleting expired backups.
• Reviewing security logs.
• Testing notification delivery.
• Removing unused software and accounts.
• Maintaining an emergency-access procedure.
• Reviewing proxy and CDN configuration.
No single plugin setting can replace secure hosting, access control, current software and responsible administration.
Privacy notices
The website owner should determine whether its public privacy notice must explain the use of security logs, login records, IP addresses, Live Traffic or backup systems.
A privacy notice may need to explain:
• Which security information is collected.
• Why it is processed.
• Which users or visitors may be affected.
• How long it is retained.
• Who can access it.
• Which service providers are involved.
• Whether information is transferred to another location.
• How privacy requests can be submitted.
• How security incidents are handled.
The correct wording depends on the website’s actual configuration and applicable requirements.
Do not copy a generic privacy statement without confirming that it accurately describes the website.
Suggested privacy notice text
The following text can be adapted for a website’s own privacy policy after reviewing its actual configuration:
“Security information may be processed to protect this website against unauthorised access, malicious activity and unexpected file changes. Depending on the security features enabled, this information may include IP addresses, login-attempt records, WordPress account information, request paths, browser or user-agent information and security events. These records are stored within our WordPress and hosting environment and are accessible only to authorised administrators and relevant service providers. We retain security information only for the period required for protection, investigation and operational purposes.”
This example is not a complete privacy policy and does not replace professional legal review.
If Live Traffic is disabled, the website should not claim that it records Live Traffic through this plugin.
If other security, analytics or hosting systems collect similar information, those systems should be described separately where required.
Administrator checklist
Review the following points when configuring PW Security and Backup:
• Is Live Traffic required?
• Are notification recipients correct?
• Are administrator accounts limited to authorised users?
• Is the log-retention period appropriate?
• Are IP allowlists and blocklists reviewed?
• Are scanner findings accessible only to administrators?
• Are ignored findings documented?
• Is the quarantine area protected?
• Are backup archives protected from public access?
• Are important backups stored outside the hosting account?
• Are expired backups deleted?
• Are exported logs stored securely?
• Are support screenshots redacted?
• Is the website privacy notice accurate?
• Are hosting and email providers reviewed separately?
• Is there a documented process for security incidents?
• Are emergency access and recovery procedures tested?
This review should be repeated after important website, hosting, security or organisational changes.
Common questions
Does PW Security and Backup send telemetry?
No. The plugin does not send product-usage telemetry, scan results, traffic records, login information, credentials or backup contents to PW Feed or Poyraz Web.
Does the plugin require a remote account?
No. The current version does not require a PW Feed or Poyraz Web account to use its main security, monitoring and manual backup features.
Does the plugin use a remote malware-scanning service?
No. The File Scanner operates within the website’s own WordPress and hosting environment.
Scanner findings are not automatically uploaded to an external PW Feed or Poyraz Web service.
Are backup archives uploaded to PW Feed?
No. Backup archives are created and stored within the user’s own hosting environment unless the administrator manually downloads or transfers them elsewhere.
Can the developer view my security logs?
No. PW Feed and Poyraz Web cannot automatically access the locally stored plugin configuration, security logs, findings or backups.
An administrator must voluntarily provide relevant information when requesting support.
Does the plugin store IP addresses?
It may store IP addresses when features such as failed-login protection, IP bans, security logs or Live Traffic are used.
The exact records depend on the enabled settings and website activity.
Is Live Traffic active by default?
No. Live Traffic is disabled by default.
The administrator must enable it when the additional security or diagnostic information is required.
Can Live Traffic records be deleted?
Yes. Stored Live Traffic records can be cleared through the plugin interface.
Copies may still exist in database backups, exports or other independently operated systems.
Does uninstalling the plugin delete backups?
No. Backup ZIP files are deliberately preserved during uninstall.
The administrator must review, download or manually remove preserved archives when appropriate.
Does the plugin automatically make a website privacy-compliant?
No. Privacy responsibilities depend on the website’s activities, configuration, users, location, service providers and applicable requirements.
The website owner remains responsible for privacy notices, retention, access control and request handling.
Are email notifications completely local?
Notification events are generated by the plugin, but enabled messages are sent through the WordPress email system configured by the administrator.
The hosting mail server, SMTP provider and recipient email provider may process those messages according to their own services and policies.
Can security reports be shared publicly?
They should be reviewed and redacted before sharing.
Reports and exported logs may contain IP addresses, usernames, file paths or configuration information.
Are file-integrity hashes personal information?
A SHA-256 file signature represents file content and is not a copy of the original file.
However, integrity records can also contain file paths and operational information that should be protected as part of the website’s security data.
What should be done before sending a support request?
Remove passwords, access credentials, private keys, customer information, complete backup archives and unnecessary IP addresses from the material being shared.
Provide only the minimum non-sensitive information required to describe the problem.
Responsible use
PW Security and Backup is designed to help website owners protect WordPress installations without requiring the website’s security information to be submitted to a remote PW Feed or Poyraz Web service.
Local operation provides greater control over important records, but that control also creates responsibility.
Administrators must protect access, select suitable retention periods, secure backup archives, review external service providers, disclose relevant processing where required and remove information that is no longer needed.
A privacy-conscious configuration combines:
• Limited administrator access.
• Live Traffic enabled only when necessary.
• Appropriate log retention.
• Secure notification recipients.
• Protected backup storage.
• Verified external recovery copies.
• Careful support-data sharing.
• Accurate website privacy notices.
• Regular security and privacy reviews.
PW Security and Backup provides the tools needed to monitor and protect a WordPress website. The website owner remains responsible for deciding how those tools are used within the organisation’s security, operational and privacy requirements.