PageBrain has several security policies in place to properly identify, respond to, and mitigate potential security risks. All employees, vendors and contractors working with PageBrain must follow these policies in order to best protect PageBrain’s and its customers’ data.
We’ve published these publicly for transparency, so that you can see where we are in terms of security maturity. We also hope you use these to adopt similar policies and processes at your organization.
PageBrain reviews risks on a regular basis, to ensure proper mitigations are in place.
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.
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.
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.
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.
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:
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.
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.
PageBrain catalogues assets with several pieces of information, to help identify the potential risk of the asset. Information collected is as follows:
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.
PageBrain classifies assets into three risk categories: Low Risk, Medium Risk, and High Risk. Definitions are as follows:
| Risk category | Definition |
| High risk |
|
| Medium risk |
|
| Low risk |
|
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.
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.
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:
PageBrain will document vendor information, to help in case of a potential incident. This information includes:
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.
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:
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:
PageBrain’s Security Review Team reviews and responds to potential third-party reports of security issues to [email protected] promptly.
If a suspected incident is detected, it should be responded to following the Incident response process.
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:
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.
If a suspected outage or other business continuity incident is detected, it should be responded to following the Incident response process.
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.
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.
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.
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.
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.
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.
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.
Where a third-party application supports single sign-on, it must be used.
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.
Where SSO is not used, and where possible, passwords should be randomly-generated and stored in a password manager.
Passwords should be stored encrypted at rest.
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, 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 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.
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.
To avoid potential security incidents, PageBrain requires change management controls to ensure only authorized changes are made to its environment and processes.
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.
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.
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 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.
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.
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.
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.
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.
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.
In order to detect potential vulnerabilities, the Security Review Team:
Where automated patch rollout is available, e.g., auto-updates on iOS devices, it should be enabled.
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.
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.
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.
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.
Data may be destroyed by overwriting on disk, deleting a cloud resource, encrypting and destroying the key, resetting a device, and/or physical destruction.