Our security policies

Network & infrastructure security
  • Requires explicit customer permission for accessing the production data.
  • Requires business need to access the production environment.
  • Requires SSO and MFA to manage the production environment.
  • Logs operations in the production environment, and audits these for unusual activity.
Data security
  • Encrypts data at rest and in transit.
  • Backs up data at least hourly, and tests recovery at least annually.
  • Retains data in line with our Privacy Policy.
Application security
  • Requires a peer review for source code changes.
  • Regularly conducts audits of our source code.
  • Regularly reviews potential vulnerabilities in our environment and applies relevant patches.
  • Reviews access permissions at least quarterly.
Incident response
Business practices
  • Checks references for all new employees.
  • Requires new and existing employees to regularly complete security awareness training.
  • Requires new employees to sign a non-disclosure agreement.
  • Reviews new vendors prior to using their services, and existing vendors at least annually.

Personnel policy

PageBrain reviews risks on a regular basis, to ensure proper mitigations are in place.

Reference Checks

As part of its hiring process, PageBrain does not perform criminal background checks, but does employ a reference check process for prospective employment candidates prior to or within 30 days of their hire date.

Security Awareness training

All employees must complete PageBrain’s information security awareness training as part of their initial onboarding and thereafter, while still under contract, on an annual basis.

Performance Reviews

All full time employees must complete a biannual Performance Review, the results of which are signed and dated by both the employee and their manager, and uploaded to the employee’s personnel files in the HR system.

Risk assessment policy

PageBrain reviews risks on a regular basis, to ensure proper mitigations are in place.


This policy covers any risk that could affect confidentiality, availability, and integrity of PageBrain’s key information assets and systems.

Risk assessments can be conducted on any information system, to include applications, servers, and networks, and any process or procedure by which these systems are administered and/or maintained.

Risk assessment

The Security Review Team is responsible for completing periodic information security risk assessments for the purpose of determining areas of vulnerability, and to identify and initiate appropriate remediations.

A risk register should include:

  • Identification of the risk
  • What mitigations have been put in place
  • Acceptance of the residual risk

The execution, development and implementation of remediation programs is the joint responsibility of the Security Review Team. Employees are expected to cooperate fully with any risk assessment being conducted on systems for which they are held accountable. Employees are further expected to work with the Security Review Team in the development and implementation of a remediation plan.


Risks should be evaluated on an annual basis.

Information classification policy

To understand its potential exposure from a security risk, issue or incident, PageBrain regularly catalogues and classifies its data and other in-scope assets, in order to apply risk-based controls.

Assets are anything that has value to the organization, including but not limited to, customer data, production data, financial data, intellectual property, and any material non-public information.

Asset cataloging

PageBrain catalogues assets with several pieces of information, to help identify the potential risk of the asset. Information collected is as follows:

  • Description, i.e. what is the asset?
  • Risk, i.e. what is the asset risk classification?
  • Use, i.e. how is this asset used?
  • Location, i.e. where is it stored, used, and backed up?
  • Sharing, i.e. is it shared with any third parties, such as vendors? Which specific third parties?

If new data is catalogued, or data use changes, it should be specifically reviewed to verify that its collection and use is in line with PageBrain’s Privacy Policy.

Asset risk classification

PageBrain classifies assets into three risk categories: Low Risk, Medium Risk, and High Risk. Definitions are as follows:

Risk category Definition
High risk
  • Data: protection is mandated by confidentiality agreements, labor codes, specific laws and regulations (e.g. PCI DSS, HIPAA, GDPR), or data is subject to breach reporting requirements, or disclosure would have a significant adverse impact on PageBrain (e.g., user accounts database).
  • Hardware and software systems: compromise would have a significant adverse impact on PageBrain (e.g. the login.pagebrain.ai control plane service).
Medium risk
  • Data: not generally available to the public, and disclosure would have some adverse impact on PageBrain (e.g. internal engineering documentation).
  • Hardware and software systems: compromise would have some adverse impact on PageBrain (e.g. cloud VM running production monitoring system).
Low risk
  • Data: publicly available, or disclosure would have no adverse operational or financial impact on PageBrain (e.g. pagebrain.ai website source code). May still have some limited reputational impact.
  • Hardware and software systems: compromise would have no adverse impact on PageBrain (e.g. testbed cloud VM with no user data or privileged access).

When multiple classifications may apply, the highest applicable classification is used. For example, if a machine is low-risk by itself, but can be used to access high-risk data, its overall classification is also high-risk.


PageBrain should review the data it collects and processes, and update the data register, quarterly.

Third party vendor review policy

PageBrain reviews vendor security practices before contracting, and on a regular basis, to ensure vendors properly handle PageBrain’s customer data, confidential data, and other data.


This policy only applies to vendors or contractors handling PageBrain or its customers’ data.


Vendors’ security practices should be initially evaluated as part of their contract review, and while still in use, on an annual basis.

Contractors must read and acknowledge PageBrain’s security policies as part of their onboarding. Contractors must complete PageBrain’s information security training as part of their onboarding and thereafter, while still under contract, on an annual basis.

Vendor assessment

As part of vendor evaluation and contracting, vendors’ security practices should be reviewed to ensure they sufficiently protect PageBrain’s and its customers’ data.

The requirements for a vendor may change based on the risk classification of the assets they are handling (see the Information classification policy), such as sensitive data, or access to production resources; and may change during a contract if a vendor’s scope or responsibilities change.

PageBrain will:

  1. Ask vendors for their SOC 2 type II or type I report for an overview of their current security practices. If a SOC 2 report does not exist or where insufficient information is provided, PageBrain will ask the vendor to complete the VSAQ.
  2. Review the vendor’s responses and compare these to PageBrain’s security policies to identify any gaps where the vendor may have weaker policies.
  3. For each notable gap or where insufficient information is provided, PageBrain can: ask the vendor to make a change or provide additional information, implement a mitigating control, or accept the risk. These should be documented in the risk register.

PageBrain will document vendor information, to help in case of a potential incident. This information includes:

  • Vendor name, i.e. Which vendor?
  • Vendor contact information, i.e. How do we contact the vendor? List different contacts for billing, support, and/or security where they apply.
  • Type of data shared, i.e. What types of data from PageBrain does the vendor collect or otherwise have access to?
  • Terms of Service for services provided by the vendor
  • Security report or questionnaire shared by the vendor

Incident response policy


PageBrain’s customers are dependent on our services operating as normal. Proper detection and response to incidents that may impact the integrity, confidentiality or availability of services and data is critical to the operation of PageBrain.

The following minimum standards apply to PageBrain’s assets as managed by employees, contractors and vendors. These recommendations represent the recommended minimum efforts necessary for incident detection and response.

Incident detection

An incident could be detected internally by an employee in their course of work, by an employee or vendor doing a review of PageBrain’s security posture, or an external third party reporting a potential vulnerability to us.

If you see something, say something. All PageBrain employees should immediately report suspected security incidents or suspicious activity that occurs at PageBrain, including but not limited to security incidents, physical injury, theft, property damage, denial of service attacks, threats, harassment, abuse of individual user accounts, forgery and misrepresentation. Suspicious activity can be reported to the Security Review Team [email protected]. Violations of the Code of Conduct should be reported to the Chief Operating Officer (COO).

All employees should watch for potentially suspicious activities, including:

  • Warnings from antivirus tools
  • Unexpected system reboots and/or sudden degradation of system performance
  • Password reset notifications
  • Modification or defacement of websites
  • New open network ports on a system

PageBrain regularly reviews logs for detecting and tracking attempted intrusions and other suspicious activity. These include git, cloud, networking, SaaS tool, and other infrastructure logs.

The Security Review Team:

  • Ensures that a very high level of logging is enabled
  • Checks logs regularly for suspicious activities and entries
  • Looks for missing time spans in logs
  • Checks for repeated login failures or account lockouts
  • Investigates unexpected system reboots

PageBrain’s Security Review Team reviews and responds to potential third-party reports of security issues to [email protected] promptly.

Incident response and remediation

If a suspected incident is detected, it should be responded to following the Incident response process.

BCP/DR policy


PageBrain’s customers are dependent on our services operating as normal. Proper planning, monitoring, and recovery steps are critical to address incidents that may impact the integrity or availability of services and data is critical to the operation of PageBrain. Business Continuity and Disaster Recovery is a set of processes and techniques used to help an organization recover from a disaster and resume routine business operations.


The following minimum standards apply to PageBrain’s assets as managed by employees, contractors and vendors. These include but are not limited to: cloud service providers, cloud regions, major components within cloud regions, key vendors (those included in our vendor assessment, and key open-source components.


PageBrain reviews its backups, and any BCP/DR plans annually with a walkthrough exercise. PageBrain tests its ability to restore production data at least annually.


PageBrain regularly reviews backups and service redundancy to ensure they can be used in the event of an outage. The Security Review Team:

  • Ensures backups for key services are in place
  • Tests backups and restore procedures
  • Reviews proposed and existing architecture plans for resiliency
  • Implements monitoring tools to detect potential continuity issues for key services

Outage detection

An incident could be detected internally by monitoring tools, by an employee in their course of work, or reported by a third party including customers.

Outage response and remediation

If a suspected outage or other business continuity incident is detected, it should be responded to following the Incident response process.

Access control policy

PageBrain limits access control based on job requirements, following the principle of least privilege.


This policy applies to PageBrain’s internal systems, including its production network, production servers, and SaaS applications.

This policy applies throughout the entire lifecycle of employee, contractor, or vendor access, from onboarding of new individuals who need access, to the removal of existing individuals who no longer need access.

Access to internal systems

Where possible, access policies are enforced by technical measures.

PageBrain should implement monitoring on its systems where possible, to record logon attempts and failures, successful logons and date and time of logon and logoff. Activities performed as administrator are logged where it is feasible to do so.

Personnel who have administrative system access should use other less powerful accounts for performing non-administrative tasks.

Where possible, more than one person must have full rights to any critical piece of infrastructure serving or storing production services or customer data.

Granular access controls

PageBrain systems must have sufficient granularity to allow appropriate authorized access. There is a delicate balance between protecting the data and permitting access to those who need to use the data for authorized purposes. PageBrain recognizes that balance.

End user devices

Employees, contractors, and vendors are responsible for safe handling and storage of PageBrain-provided end user devices. If a device is lost or stolen, the loss must be immediately reported as an incident.

Changing roles or responsibilities

Terminated employees must have their accounts disabled within 1 business day of transfer or termination.

Transferred employee access is reviewed and adjusted as found necessary. Since there could be delays in reporting changes in user responsibilities, periodic user access reviews are conducted by the Security Review Team.

Password policy

To avoid potential security incidents, PageBrain requires employees to follow password requirements.


This policy applies to passwords for any application or server accessed by PageBrain employees, contractors, or vendors. It does not apply to the passwords customers of PageBrain use to access the PageBrain service.

Password strength

Passwords must be unique for each use.

Default passwords on all systems are changed after installation.

Passwords do not need to be regularly rotated. However, if a password is known or thought to be compromised, it must be rotated to a new password.

Single sign-on

Where a third-party application supports single sign-on, it must be used.

Multi-factor authentication

Where a third-party application supports multi-factor authentication, it must be used. Use of multi-factor is enforced where possible.

Acceptable forms of multi-factor authentication include authentication apps or a WebAuthn token. Embedded tokens (e.g., TouchID) are permitted. WebAuthn hardware or embedded hardware tokens are preferred to authentication apps.

Password manager

Where SSO is not used, and where possible, passwords should be randomly-generated and stored in a password manager.

Encryption at rest

Passwords should be stored encrypted at rest.

Requirements for specific use cases


Access to servers, for both production as well as development and testing infrastructure, must be with a password and MFA or with per-user public keys (e.g., SSH keys). Only PageBrain-based network authentication is permitted for services not exposed to the Internet.

Automated processes

Automated processes, including deployment or CI/CD tools, should use passwords or API keys to access and communicate with other systems. These should be encrypted at rest.

End user devices

End user devices must use passwords to encrypt their disks and unlock the device. These must be unique for each individual but may be reused across an individual’s devices.

SaaS applications or other software

Access to third party applications must use SSO where possible, MFA where possible, and enforce MFA where possible. Each application must have a randomly-generated password stored in a password manager.

An individual’s password for their password management vault must be unique.

Change management policy

To avoid potential security incidents, PageBrain requires change management controls to ensure only authorized changes are made to its environment and processes.


Code changes

Changes to code in PageBrain’s environment made by an employee or contractor must be tested and approved by another employee prior to being merged and rolled out.

PageBrain uses branch protection rules on GitHub to require a second review prior to merging code.

Exceptionally, employees can push changes without a second review where they are required to mitigate an incident. Changes pushed without prior approval are tagged and audited after the fact, within 2 business days.

Changes to update dependencies, publish documentation, changes to the marketing website, or non-substantive code changes are exempt from this policy.


Dependencies can be updated without requiring a separate reviewer. PageBrain reviews the release notes for a dependency prior to merging the changes.


Documentation can be updated without requiring a separate reviewer.

Infrastructure changes

Employees should notify others prior to making changes to PageBrain’s infrastructure, e.g., over Slack. Where infrastructure is codified and uses a deployment tool, infrastructure changes should be approved by another employee prior to being deployed.

Customer accounts

PageBrain may make changes to customers’ networks and accounts in PageBrain at their request. Changes are initiated by customer support tickets.

PageBrain may also make changes to customer environments without the customer initiating the request, such as when required by law or due to an urgent security issue.

Security policies

Security policies must have a change log to allow auditing of past changes, including when and by whom these changes were made. PageBrain stores these security policies in GitHub and uses git to track changes.

PageBrain will review and evaluate its security policies, adapt them as needed due to changing risks, and validate if the implemented information security continuity controls are sufficient on a quarterly basis.

Testing policy

To avoid potential security incidents, PageBrain requires testing of its software to ensure that it functions as expected.


This policy applies to code developed by PageBrain for its clients or run on its production servers.

Code changes

Changes to production code which alter PageBrain’s product functionality should be tested by PageBrain’s continuous integration (CI) system prior to being merged. Testing should not be conducted locally in a development environment or in production.

Exceptionally, changes to production code may be merged without first testing them, such as to resolve an incident. See the Change management policy.

Changes to production code which do not alter product functionality, e.g., changes to documentation, may be but do not need to be tested.

Client releases

When a new version of the PageBrain client is built, it should be tested prior to being released. This includes testing major product features on supported platforms.

New functionality should be released as part of an unstable track prior to being incorporated in stable client releases. New functionality may be released directly to a stable client to address an incident, such as a security issue.

Infrastructure changes

Changes to PageBrain’s production infrastructure should be tested where possible.

Where possible, infrastructure should be implemented ‘as code’, so that it can be reviewed, approved, and tested as other code changes are.

Patch management policy

To avoid potential security incidents, PageBrain regularly reviews potential vulnerabilities in its environment and applies relevant patches.


This patch management policy applies to PageBrain’s infrastructure, including Linux servers running production infrastructure in third party cloud providers; development or testing infrastructure, including Linux, Windows, and macOS machines; and end user devices such as laptops and phones, including Linux, Windows, macOS, iOS, and Android devices. Test or demo environments are exempt from this policy.

This patch management policy also applies to the software PageBrain ships to customers.

Vulnerability and patch detection

In order to detect potential vulnerabilities, the Security Review Team:

  • Subscribes to and reviews announcements for security patches in OSes from vendors and open source maintainers for servers, development infrastructure, and end user devices.
  • Reviews dependencies for security patches prior to new builds for software that PageBrain ships.

Where automated patch rollout is available, e.g., auto-updates on iOS devices, it should be enabled.

Review and approval

Security patches can be applied without further approval.


PageBrain should review any new security patches when they are released by vendors, or when building a new release, which in practice is about monthly.

PageBrain should patch security vulnerabilities as soon as possible. The expected timeline for remediation, from when a patch is available to when it is applied, is 90 days.


Where a patch is not yet available, or cannot be applied, PageBrain should put in place mitigations as appropriate to prevent a vulnerability from being exploited. PageBrain should also put in place mitigations if a vulnerability is known to be actively exploited in the wild.

Mitigations can include: removing functionality, limiting who can access a service, or taking down a service.

Data retention and deletion policy

PageBrain must retain certain kinds of data for a minimum amount of time, to comply with legal requirements. At the same time, PageBrain wants to avoid retaining any identifiable data for longer than is necessary, in case of a breach.


This policy applies to all data assets handled by PageBrain, including data from customers, potential customers, third parties, and employees.


PageBrain should review the data it retains as part of reviewing its data register quarterly.

Retention period

Data should be retained for a set period of time, depending on the type of data:

Category Data Retention period
Corporate Charter and bylaws Indefinite
Shareholder records Indefinite
Board minutes Indefinite
Policies and procedures Indefinite
Contracts Indefinite
Financial Accounts payable/ receivable 7 years
Financial statements Indefinite
Sales records 7 years
Expense records 7 years
Payroll records 7 years
Insurance Insurance records Indefinite
Inventions Patents and patent applications Indefinite
Copyright and copyright applications Indefinite
Trademark and trademark applications Indefinite
Licenses Indefinite
Employee Personnel files Indefinite
Compensation information Indefinite
Benefit plans Indefinite
Customer Contracts Indefinite
Payment and billing information 7 years
Usage logging and analytics 5 years
Support communications 5 years

*In response to a customer request and in compliance with legal requirements, PageBrain may also delete customer data prior to the end of the retention period.

Where not specified, customer data should be retained no longer than is needed to provide the service, and anonymized or deleted afterwards.

Privacy Policy

PageBrain must delete customer data in accordance with the commitments, if any, made in PageBrain’s Privacy Policy. If the privacy policy is updated, the above retention periods should also be updated to reflect any changes.

Deletion method

Data may be destroyed by overwriting on disk, deleting a cloud resource, encrypting and destroying the key, resetting a device, and/or physical destruction.