Security at Policy Confirm
Policy Confirm holds your policies and the record of who confirmed them, so your security team will ask how that data is protected. This page answers it: where the data is hosted, how it is encrypted, who can reach it, and how changes and incidents are handled. It is written for the security, IT and procurement reviewers who assess Policy Confirm as a supplier, and for the ISO 27001, SOC 2 and GDPR reviews that follow.
Google Cloud, nothing else
The whole service runs on Google Cloud managed services. Policy Confirm runs no servers of its own, so patching, physical security and network defence sit with Google.
EU or US, your choice
Two separate production environments. Your data lives in the region you pick when you sign up and is never replicated to the other.
No passwords to breach
Administrators sign in with a single-use link or their Microsoft account. Recipients prove control of their email address. Nobody has a Policy Confirm password.
Security controls at a glance
The controls that protect your policies and confirmation records, grouped the way a vendor security assessment or supplier review asks for them: hosting and data residency, encryption, identity and access, change management, logging, incident response and data protection. Each row says whether the control is in place today, so you can lift the answers straight into your questionnaire.
| Control area | Control | Status |
|---|---|---|
| Hosting Google Cloud managed services only, no servers of our own. Google holds ISO 27001, ISO 27017, ISO 27018 and SOC 1, 2 and 3 for the services used. | Google Cloud managed services only, no servers of our own. Google holds ISO 27001, ISO 27017, ISO 27018 and SOC 1, 2 and 3 for the services used. | In place |
| Data residency Two separate production environments, United States and European Union, each with its own project, database, file storage, user directory and backups. Data is never replicated between them. | Two separate production environments, United States and European Union, each with its own project, database, file storage, user directory and backups. Data is never replicated between them. | In place |
| Encryption in transit TLS 1.2 or higher on every connection. HTTPS is enforced on every application URL. | TLS 1.2 or higher on every connection. HTTPS is enforced on every application URL. | In place |
| Encryption at rest AES-256 with Google-managed keys for the database, file storage and backups. | AES-256 with Google-managed keys for the database, file storage and backups. | In place |
| Authentication Passwordless: a single-use email link or Microsoft Entra ID for administrators, a one-time code or Microsoft sign-in for recipients. No passwords are stored anywhere. | Passwordless: a single-use email link or Microsoft Entra ID for administrators, a one-time code or Microsoft sign-in for recipients. No passwords are stored anywhere. | In place |
| Customer SSO and MFA When Microsoft sign-in is used, the customer's own Entra ID tenant controls authentication, so its MFA, conditional access and device policies apply. | When Microsoft sign-in is used, the customer's own Entra ID tenant controls authentication, so its MFA, conditional access and device policies apply. | In place |
| Authorization Role-based access enforced by server-side security rules on every request, with each organization's data isolated in its own document tree. | Role-based access enforced by server-side security rules on every request, with each organization's data isolated in its own document tree. | In place |
| Staff access A small number of named individuals, MFA enforced, least privilege, and confidentiality obligations. Customer data is accessed only at the customer's request or to keep the service running. | A small number of named individuals, MFA enforced, least privilege, and confidentiality obligations. Customer data is accessed only at the customer's request or to keep the service running. | In place |
| Secrets management Credentials are kept in a managed secret store, never in source code. | Credentials are kept in a managed secret store, never in source code. | In place |
| Backups Daily backups kept for 14 weeks, point-in-time recovery, and deletion protection on production databases. Backups stay in the customer's region. | Daily backups kept for 14 weeks, point-in-time recovery, and deletion protection on production databases. Backups stay in the customer's region. | In place |
| Record integrity Every confirmation carries a timestamp, the IP address, a unique confirmation ID and a hash of the exact document version shown. Finished cycles are frozen into proofs that do not change when a policy is edited later. | Every confirmation carries a timestamp, the IP address, a unique confirmation ID and a hash of the exact document version shown. Finished cycles are frozen into proofs that do not change when a policy is edited later. | In place |
| Change management Every change is a registered item that moves through quality check, development, test and approval before it is deployed. | Every change is a registered item that moves through quality check, development, test and approval before it is deployed. | In place |
| Test environment A separate environment with no customer data and its own credentials. Every change is verified there before release. | A separate environment with no customer data and its own credentials. Every change is verified there before release. | In place |
| Secure development Private source repository, pull-request workflow, an automated build and test pipeline on every change, and staged releases one region at a time. | Private source repository, pull-request workflow, an automated build and test pipeline on every change, and staged releases one region at a time. | In place |
| Logging Centralized backend logging, audit fields on every record, and a per-cycle log of every email sent to a recipient. | Centralized backend logging, audit fields on every record, and a per-cycle log of every email sent to a recipient. | In place |
| Incident response A documented process covering detection, containment, recovery and review. Affected customers are notified without undue delay, in line with GDPR Article 33 and the DPA. | A documented process covering detection, containment, recovery and review. Affected customers are notified without undue delay, in line with GDPR Article 33 and the DPA. | In place |
| Data retention and deletion A 30-day export window after a subscription ends, deletion within 90 days after that, and a documented retention schedule in the privacy policy and the DPA. | A 30-day export window after a subscription ends, deletion within 90 days after that, and a documented retention schedule in the privacy policy and the DPA. | In place |
| Sub-processor management A published list, written agreements consistent with GDPR Article 28(4), and 30 days' notice before a sub-processor is added or replaced. | A published list, written agreements consistent with GDPR Article 28(4), and 30 days' notice before a sub-processor is added or replaced. | In place |
| Data processing agreement A GDPR Article 28 data processing agreement, published and part of the terms of service. | A GDPR Article 28 data processing agreement, published and part of the terms of service. | In place |
| Security certification Google Cloud holds ISO 27001 and SOC 2 for the infrastructure. Policy Confirm is not certified in its own right. | Google Cloud holds ISO 27001 and SOC 2 for the infrastructure. Policy Confirm is not certified in its own right. | Not in place |
| External penetration test An independent test can be arranged at a customer's request. Security review is part of every change in the meantime. | An independent test can be arranged at a customer's request. Security review is part of every change in the meantime. | On request |
Status as of , matching version 1.0 of the security controls overview below.
The full document
Security controls overview
- Version
- 1.0
- Date
- 30 September 2026
- Length
- 11 pages
- Classification
- Confidential
The overview describes every control above in detail: hosting and data residency, identity and access, encryption and record integrity, backups, development and change management, logging, incident response, business continuity, and regulatory alignment. It is written to answer the questions vendor security assessments ask, and we are happy to complete your own questionnaire alongside it.
It is classified confidential and shared with prospective and existing customers who are assessing Policy Confirm as a supplier. Request it by email and tell us a little about who you are, and we will send it to you.
Request the documentCommon questions
Where is our data stored?
In the region your organization chose when it signed up: Google Cloud in the United States, or Google Cloud in the European Union. Database, file storage, serverless functions and backups all stay in that region, and nothing is replicated to the other.
Is Policy Confirm ISO 27001 or SOC 2 certified?
The infrastructure is: Google Cloud holds ISO 27001, ISO 27017, ISO 27018 and SOC 1, 2 and 3 for the services Policy Confirm uses. Policy Confirm itself is not certified in its own right. The security controls overview describes what is in place instead, and we complete customer questionnaires on request.
Can we see the full security documentation?
Yes. The security controls overview is shared with organizations assessing Policy Confirm as a supplier. Email contact@policyconfirm.com with your organization and role, and we will send it. The data processing agreement and the list of sub-processors are published openly on this site.