A Security Annex is the document that describes the technical and organisational security measures a SaaS vendor maintains. It forms part of the DPA (GDPR Article 32 specifies that security measures must be documented) and is increasingly required as a standalone exhibit in enterprise contracts. Many enterprise procurement teams will not sign without one.
What a Security Annex Is
A Security Annex (also called Security Addendum, Information Security Schedule, or Security Policy Exhibit) is a structured document covering the vendor's information security controls. It:
- Satisfies GDPR Article 28(3)(c) and Article 32 requirements for documented security measures
- Answers the security sections of enterprise DDQs before they are formally asked
- Gives the customer a contractually binding reference for the security standards you maintain
- Creates the baseline against which any security incident is assessed
Unlike a general security policy (which is internal), the Security Annex is designed to be shared with customers and incorporated into contracts.
Security Annex Checklist
1. Access Control
- Role-based access control (RBAC) in place for all systems containing customer data
- Principle of least privilege applied — access limited to what is needed for the role
- Multi-factor authentication (MFA) required for all access to production systems and systems containing customer data
- Privileged access management — elevated access rights require additional authentication and are logged
- Access review process — access rights reviewed at a minimum quarterly; immediately revoked on termination
- Customer data access limited to named personnel; list of authorised personnel maintained
2. Encryption
- Data encrypted at rest (minimum AES-256)
- Data encrypted in transit (TLS 1.2 minimum, TLS 1.3 preferred)
- Key management process documented — who holds keys, rotation schedule, key storage
- Customer data in backups encrypted with equivalent standards
3. Network and Infrastructure Security
- Network segmentation in place — production systems isolated from development and staging
- Firewalls and intrusion detection/prevention systems (IDS/IPS) deployed
- Regular vulnerability scanning — minimum weekly automated scanning
- Penetration testing — annual independent penetration test; critical findings remediated within 30 days
- Cloud provider security configuration reviewed — CIS Benchmark or equivalent baseline
4. Patch Management
- Critical security patches applied within 72 hours of release
- High severity patches applied within 30 days
- Patch management policy documented with defined SLAs by severity
5. Incident Detection and Response
- Security monitoring in place — SIEM or equivalent log aggregation and alerting
- Incident response procedure documented and tested
- Defined incident classification: P1 (critical), P2 (significant), P3/P4 (standard)
- Customer notification timelines by incident severity (specified in the contract body)
- Forensic capability — ability to preserve evidence for post-incident analysis
6. Business Continuity and Disaster Recovery
- Business Continuity Plan documented and reviewed annually
- Recovery Time Objective (RTO): [specify for the service]
- Recovery Point Objective (RPO): [specify for the service]
- Disaster recovery testing: minimum annually; results documented
- Multi-region or geographic redundancy: [specify architecture]
- Backup testing: backups tested for restorability at minimum quarterly
7. Third-Party and Supply Chain Security
- Sub-processor/vendor security assessment conducted before onboarding
- Security requirements imposed on sub-processors through contractual obligations
- Sub-processor list maintained and disclosed (link to current list)
- Annual review of key sub-processors' security posture
8. Physical Security
- Data centre physical security: access controls, CCTV, environmental monitoring
- If using cloud infrastructure: cloud provider's physical security certifications referenced
- Visitor access controls for any facilities hosting customer data
9. Personnel Security
- Background screening for personnel with access to customer data (appropriate to role and jurisdiction)
- Security training — all staff receive security awareness training annually
- Termination process — access revoked immediately on departure
- Non-disclosure obligations for all personnel with access to customer data
10. Development Security
- Secure development lifecycle (SDL) in place
- Code review process — peer review required before production deployment
- OWASP Top 10 security vulnerabilities addressed in development process
- Dependency/SCA (software composition analysis) scanning for third-party libraries
- Separate development, staging, and production environments
- No customer data in development or staging environments
11. Certifications and Compliance
- ISO 27001 certification (scope: [specify]) — certificate valid until [date]
- SOC 2 Type II report (period ending [date]) — available to customers under NDA
- GDPR compliance — DPA available, sub-processor management in place
- DORA compliance statement (if selling to financial services)
- Any sector-specific certifications (PCI DSS, HIPAA, etc.)
Format Recommendations
A Security Annex should be:
Concise but specific: Enterprise procurement teams read many security annexes. A clear, well-structured document that answers the key questions directly is more effective than a 40-page policy document.
Version-controlled: Include a version number and effective date. When certifications are renewed or controls are updated, update the annex and notify customers.
Incorporated by reference in the contract: The DPA or MSA should reference the Security Annex and confirm that the vendor maintains the stated controls.
Updated annually: Outdated security documentation is a red flag. Update the annex when you renew certifications, conduct penetration tests, or materially change your security architecture.