If your SaaS company processes personal data on behalf of customers — and virtually every B2B SaaS does — you are a data processor under GDPR. And Article 28(3)(c) requires that your data processing agreement (DPA) with each controller includes a commitment to implement technical and organisational measures (TOMs) to protect personal data.
But a DPA clause saying "we implement appropriate security measures" isn't enough. Enterprise customers will ask for your processor security policy — a standalone document that details what you actually do. This guide explains what that document needs to cover, how to structure it, and how it maps to the frameworks your customers audit against.
Processor vs Controller: Why It Matters for Security Documentation
The distinction is critical:
| Role | Definition | Security obligation |
|---|---|---|
| Controller | Determines purposes and means of processing | Art. 24 — demonstrate compliance; Art. 25 — privacy by design; Art. 32 — TOMs |
| Processor | Processes data on controller's instructions | Art. 28(3)(c) — implement controller-agreed TOMs; Art. 32 — appropriate security; Art. 33(2) — notify controller of breaches |
| Sub-processor | Processor engaged by processor | Art. 28(4) — same obligations as processor via back-to-back DPA |
Most B2B SaaS companies are processors. They store and process their customers' data. That means every customer can demand — and many enterprise customers will demand — documentation of your security measures. A processor security policy is what you give them.
What Art. 28(3)(c) Actually Requires
Article 28(3)(c) requires processing agreements to stipulate that the processor:
"takes all measures required pursuant to Article 32"
Article 32 requires "appropriate technical and organisational measures" taking into account:
- The state of the art
- The costs of implementation
- The nature, scope, context, and purposes of processing
- The risks to the rights and freedoms of natural persons
Article 32(1) lists specific examples:
- (a) Pseudonymisation and encryption of personal data
- (b) Ongoing confidentiality, integrity, availability, and resilience of processing systems
- (c) Ability to restore access in the event of a physical or technical incident
- (d) Regular testing, assessment, and evaluation of effectiveness of TOMs
What a Processor Security Policy Must Cover
Here are the 10 sections every processor security policy should include:
1. Scope and Purpose
Define what processing the policy covers (which customer data, which systems), who it applies to (employees, contractors, sub-processors), and the legal basis (GDPR Art. 28(3)(c), Art. 32). Include effective date and review cycle (at minimum annually).
2. Encryption
Document your encryption standards specifically:
- Data at rest: Algorithm (e.g. AES-256), key management approach (managed by cloud provider KMS or separate HSM), database-level or disk-level
- Data in transit: TLS version (1.2 minimum, 1.3 preferred), certificate management, no legacy protocols (SSLv3, TLS 1.0/1.1)
- Backup encryption: Encrypted at source before transfer, same standard as primary storage
- Key rotation: Frequency and process
Vague statements like "we use industry-standard encryption" are not sufficient. Enterprise customers want to know: which algorithm, which key length, which provider?
3. Access Control
This is the highest-scrutiny area in any security questionnaire. Document:
- Principle of least privilege: Role-based access control (RBAC), access to customer data limited to those with legitimate need
- Multi-factor authentication (MFA): Required for all production system access; specify which systems and which MFA methods
- Privileged access management (PAM): How privileged accounts (database admin, cloud root) are managed, whether just-in-time access is used
- Access reviews: Frequency (quarterly minimum for SOC 2 CC6.3), process for removing access promptly on role change or termination
- Contractor and vendor access: Scoped access, time-limited, monitored
4. Network Security
- Network segmentation (customer data in isolated VPC/VLAN from management plane)
- Firewall rules — deny by default, whitelist approach
- DDoS protection (Cloudflare, AWS Shield, or similar)
- Intrusion detection/prevention (IDS/IPS)
- VPN requirement for remote access to production systems
5. Application Security
- Secure development lifecycle (SDLC): security requirements, secure coding standards, code review
- Dependency scanning (SAST/SCA tools: Snyk, Dependabot, etc.)
- Dynamic testing (DAST) and web application firewall (WAF)
- Penetration testing: frequency (annually minimum), scope, whether third-party or internal
- Vulnerability disclosure process
- Patch management SLA (critical patches: 24-72h; high: 7-14 days; medium: 30 days)
6. Monitoring, Logging, and Audit
- Centralised log management: what is logged (access events, authentication, privileged operations, API calls to customer data), retention period
- Security Information and Event Management (SIEM) or equivalent alerting
- Audit trail for access to customer data — essential for demonstrating accountability
- Availability monitoring and alerting (uptime SLA commitments)
7. HR and Personnel Security
- Background checks: pre-employment, scope (criminal record, employment verification, identity), applicable jurisdictions
- Confidentiality agreements: signed before access to customer data, scope survives termination
- Security training: frequency (annually minimum), content (phishing, social engineering, data handling), tracked completion
- Acceptable use policy: personal devices, cloud applications, password standards
- Offboarding process: access revocation timeline (same day for voluntary, immediate for involuntary termination)
8. Incident Response and Breach Notification
Art. 33(2) requires processors to notify controllers "without undue delay" after becoming aware of a breach. Best practice is 24-48 hours, giving the controller time to meet their own 72-hour DPA notification obligation.
Document:
- Incident classification (P0/P1/P2 or Critical/High/Medium)
- Detection and escalation process (who is notified, when)
- Controller notification timeline: 24-48 hours from confirmed breach
- Notification content: nature of breach, data categories affected, estimated data subjects, likely consequences, measures taken
- Post-incident review process
9. Business Continuity and Disaster Recovery
- Recovery Time Objective (RTO) and Recovery Point Objective (RPO) — be specific and commit to SLAs you can actually meet
- Backup strategy: frequency, locations (geographically redundant), retention, tested restoration
- BCP/DR plan: documented, tested at least annually
- Uptime SLA and historical uptime (link to status page)
10. Sub-processor Management
Art. 28(4) requires processors to impose equivalent obligations on sub-processors via back-to-back DPAs. Document:
- Sub-processor list (maintained and updated on change with controller notification)
- Due diligence process before engaging sub-processors
- Contractual safeguards (DPA, security requirements, right to audit)
- International transfer mechanisms for sub-processors in non-adequate countries
How Processors Are Audited: Art. 28(3)(h)
Article 28(3)(h) gives controllers the right to audit processors. In practice, most enterprise customers exercise this right via:
- Security questionnaires (VSAQ, SIG Lite, custom) — answered from your processor security policy
- SOC 2 Type II report — the most common substitute for an on-site audit for cloud vendors
- ISO 27001 certificate — widely accepted in European enterprise procurement
- On-site or virtual audit — uncommon for SaaS but possible for high-value contracts or sensitive data categories
A processor security policy supported by a SOC 2 Type II report or ISO 27001 certificate closes the vast majority of enterprise security requirements.
Processor Security Policy vs Other Documents
| Document | Audience | Purpose |
|---|---|---|
| Processor Security Policy | Customers (controllers), auditors | Demonstrate Art. 28(3)(c) TOMs commitment — external-facing |
| Information Security Policy | Employees, internal stakeholders | Internal governance of security programme — internal |
| DPA (Data Processing Agreement) | Customers | Legal contract for processing relationship — contractual |
| Sub-Processor List | Customers | Transparency on who else processes their data — operational |
| Trust Centre | Prospects, customers | Public-facing security overview — marketing + compliance |
Common Mistakes in Processor Security Policies
- Vague language: "Industry-standard encryption" tells auditors nothing. Name the algorithm, key length, and implementation.
- No breach notification timeline: Art. 33(2) requires notification to the controller. "Promptly" isn't enough — commit to a specific SLA (24-48 hours).
- No sub-processor information: Customers need to know what Art. 28(4) back-to-back DPAs you have in place.
- No version control: Your policy should have a version number, date, and owner. Customers may request historical versions post-incident.
- Not updated after incidents or infrastructure changes: A stale policy is worse than none — it's evidence of negligence.
- Covering only GDPR: Many enterprise customers need SOC 2 and ISO 27001 mapping. A good processor security policy maps to all relevant frameworks.
Framework Mapping
| Policy section | GDPR Art. 32 | SOC 2 CC | ISO 27001 Annex A |
|---|---|---|---|
| Encryption | Art. 32(1)(a) | CC6.1, CC6.7 | A.10.1, A.8.24 |
| Access Control | Art. 32(1)(b) | CC6.1, CC6.2, CC6.3 | A.9.1–A.9.4 |
| Network Security | Art. 32(1)(b) | CC6.6, CC6.7 | A.8.20–A.8.22 |
| Application Security | Art. 32(1)(d) | CC8.1, CC7.1 | A.8.25–A.8.31 |
| Logging & Monitoring | Art. 32(1)(b) | CC7.1, CC7.2 | A.8.15–A.8.17 |
| Personnel Security | Art. 32(4) | CC1.4, CC1.5 | A.6.1–A.6.5, A.7.1–A.7.4 |
| Incident Response | Art. 33(2) | CC7.3, CC7.4, CC7.5 | A.5.24–A.5.28 |
| Business Continuity | Art. 32(1)(c) | A1.1–A1.3 | A.17.1–A.17.2 |
| Sub-processor Management | Art. 28(4) | CC9.2 | A.5.19–A.5.22 |
Related guides
- GDPR Article 32: TOMs for SaaS Founders
- What is a DPA Under GDPR?
- What is a Sub-processor Under GDPR?
- SOC 2 Gap Analysis Before Your Audit
- ISO 27001 vs SOC 2 for SaaS
Generate your Processor Security Policy → /generate/processor-security-policy | InfoSec Policy → /generate/information-security-policy | Sub-Processor List → /generate/sub-processor-list
⚠️ This guide is for informational purposes only and does not constitute legal advice. GDPR compliance depends on your specific processing activities and risk profile. Engage qualified data protection counsel.