Security Whitepaper and Trust Centre Template (ISO/IEC 27001)

Security Whitepaper and Trust Centre Content: [Organization name]

Content set for a public security overview (whitepaper) and a trust centre web page: certifications with scope-limited wording, security governance, architecture and hosting, data protection, access control, secure development, operations, resilience, incident response, sub-processors, privacy, shared responsibilities and contact points, plus the rules for what must never be published. It supports ISO/IEC 27001:2022 + Amd 1:2024 clause 7.4 (communication with interested parties) and Annex A controls A.5.1 (policies, published as appropriate), A.5.12 (information classification), A.5.14 (information transfer) and A.5.34 (privacy and PII protection), with guidance from ISO/IEC 27002:2022. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

• 1. Purpose, audience and scope
• 2. Publication rules
• 3. Ownership and approval workflow
• 4. Trust centre page structure
• 5. Whitepaper and trust centre content
• 6. Keeping the content current
• 7. Size tiers
• 8. Records and evidence
• 9. References

1. Purpose, audience and scope

This document holds the approved public description of how [Organization name] protects customer information. It feeds two outputs:

• Security whitepaper: a document of about 8 to 15 pages that prospects, procurement teams and customer security reviewers read before or instead of a questionnaire.
• Trust centre: a web page that shows current certifications, policy summaries, sub-processors, system status, security contact and a request path for NDA-gated documents.

Primary readers are customer security and procurement reviewers, data protection officers of customers, and auditors of customers. Secondary readers are prospects in early evaluation and security researchers looking for a disclosure contact.

2. Publication rules

2.1 Writing rules

2.2 What not to publish

Never publish the following on the trust centre, in the whitepaper or in marketing material:

2.3 Gated content on the trust centre

Documents the trust centre lists but releases only after a request and NDA check (tiers as in DOC-ISMS-115):

3. Ownership and approval workflow

4. Trust centre page structure

5. Whitepaper and trust centre content

5.1 Overview and commitment

Example: Quillmere Analytics Ltd provides a business analytics platform to organisations that trust us with their data. We protect that data through an information security management system (ISMS) that covers people, processes and technology, is led by management and is audited each year by an independent certification body. This page describes our controls as of [date]. Contractual commitments are set out in your customer agreement and its security addendum.

5.2 Certifications and attestations

Example: Quillmere Analytics Ltd operates an information security management system certified to ISO/IEC 27001:2022 by [CB name] (certificate [number], valid until [date]) for the development, operation and support of the Quillmere analytics SaaS platform. The certification body is accredited by [accreditation body], a signatory of the Global ACI MRA (formerly the IAF MLA). The certificate covers only that scope; other products, entities or sites are not certified unless listed here. You can confirm the certificate with the certification body or in the certificate search database it uses (for example IAF CertSearch; check its current operator under Global ACI).

Rules for this block:

• One card per certificate or report, each with standard and edition, certified entity, scope as printed, issuer and expiry.
• Show attestations in progress only as "in preparation, audit planned for [quarter]" (PUB-001), never with a badge.
• Supplier certifications (for example the cloud provider's) are listed separately under "Infrastructure provider assurance", never as your own.
• Remove or mark a card the day a certificate is suspended, withdrawn or expires (DOC-ISMS-097 section 9).

5.3 Security governance and people

Example: Our information security policy is approved by top management and reviewed every year. The Head of Engineering Operations acts as ISMS manager and chairs a quarterly security steering group with the CTO and the heads of product and customer success. We assess information security risks at least yearly and when our services change. All employees and contractors sign confidentiality terms, complete security and privacy training when they join and every year, and take part in regular phishing simulations. Staff with access to production or customer data are screened before access is granted, where local law allows.

5.4 Architecture and hosting

Example: The platform runs on [cloud provider] in two regions: a primary region for production and a second region for disaster recovery. Production, staging and development are separate environments in separate cloud accounts. Customer data is logically separated by tenant identifiers enforced in the application and the database layer. Infrastructure is defined as code and changes are reviewed and deployed through an automated pipeline. Public endpoints sit behind managed load balancers with a web application firewall and distributed denial-of-service protection from the provider.

Do not add a diagram with real account names, network ranges or component versions. A conceptual diagram with layer names is enough.

5.5 Data protection

Example: Customer data is encrypted in transit with TLS 1.2 or higher and at rest with AES-256 using keys held in the cloud provider's key management service. Access to keys is limited to the platform team and logged. We classify information in four levels and handle customer data at the highest level. Customer data is kept for the contract term; on termination it is deleted from production within 30 days and from backups within a further 35 days, after an export window if requested. Customers can export their data at any time through the API and the console in CSV and JSON formats.

5.6 Access control

Example: Staff access follows least privilege and is granted by role after owner approval. Single sign-on with multi-factor authentication is required for all staff access to production, the identity provider and our productivity suite; administrators use phishing-resistant authenticators. Production access is reviewed every quarter and removed on the last working day of a leaver. Our staff do not access customer data inside the platform unless a customer asks for support or an incident requires it, and such access is logged.

5.7 Secure development

Example: We follow a documented secure development policy. Every code change is peer reviewed and automatically checked for vulnerable dependencies, exposed secrets and common coding flaws before it can be deployed. Developers receive secure coding training every year. New features with security impact go through a threat model review. An independent penetration test of the platform and its APIs takes place at least once a year and after major architectural changes; a summary letter is available under NDA.

5.8 Operations security

Example: Company laptops are centrally managed with disk encryption, endpoint detection and response, and automatic updates. We scan our infrastructure and dependencies for vulnerabilities continuously and fix critical findings within 7 days and high findings within 30 days of detection. Security logs from the platform, cloud provider and identity provider are collected centrally, kept for 12 months and monitored for suspicious activity every working day, with automated alerts outside working hours for critical events.

5.9 Business continuity and resilience

Example: Production data is backed up every day to the second region and backups are tested by restoring them every quarter. Our disaster recovery targets are a recovery time of 8 hours and a recovery point of 24 hours for the platform. We test our continuity and recovery plans at least once a year. Current availability and incident history are shown on our status page at [status URL].

5.10 Incident response and notification

Example: We maintain an incident response plan with defined roles, severity levels and escalation paths, and we exercise it at least once a year. If we confirm a security incident that affects your data, we notify your designated contact without undue delay and within the period set in your agreement and data processing agreement, and we keep you informed until the incident is closed. As a processor we support our customers in meeting their own notification duties under data protection laws such as the GDPR.

Do not publish a fixed notification hour count unless every customer contract carries the same commitment.

5.11 Sub-processors

Example: We use a small number of sub-processors to deliver the service. The current list, with each sub-processor's purpose and location, is published at [sub-processor list URL]. Customers can subscribe to change notices and receive notice at least [30] days before a new sub-processor starts processing their personal data, with the right to object as set out in the data processing agreement.

Keep this table identical to the published list (legal-lite/subprocessor-list).

5.12 Privacy

Example: For customer data in the platform we act as a processor on our customers' instructions; for our own staff and business contact data we act as controller. A data processing agreement, including transfer terms where needed, is part of every customer contract. Our privacy notice explains how we handle personal data we control. Requests from individuals about customer data are passed to the relevant customer without delay.

5.13 Shared responsibilities

Example: Security in a SaaS service is shared. We secure the platform, its infrastructure and our staff access. Customers are responsible for managing their own users and roles, enabling single sign-on or MFA for their accounts, deciding what data they upload, protecting their exports and integrations, and reporting suspected misuse of their accounts to us.

5.14 Security contact and vulnerability disclosure

Example: Report suspected vulnerabilities to [security@example.com] or through [disclosure form]. We acknowledge reports within 3 working days, will not take legal action against good-faith research that follows our disclosure policy, and ask you not to access customer data or disrupt the service. Our contact details are also published in /.well-known/security.txt in the format described in RFC 9116. For customer security questions, contact [trust@example.com] or your account manager.

6. Keeping the content current

At each scheduled review, the ISMS manager compares the live page and the current whitepaper with this source text, records any differences, and corrects them.

7. Size tiers

8. Records and evidence

9. References

Related templates: isms/security-questionnaire-answer-library, isms/customer-security-addendum, isms/certification-mark-usage, compliance/statement-of-applicability, compliance/incident-response-plan, legal-lite/subprocessor-list, legal-lite/dpa, isms/control-evidence-matrix.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 clause 7.4 and Annex A controls A.5.1, A.5.12, A.5.14 and A.5.34, with ISO/IEC 27002:2022 as guidance. The text, rules and example content are original. Control numbers are cited with short descriptive labels; no ISO/IEC text is reproduced, and you need the official standards to implement the controls. Laws are mentioned only as international examples. Check the current editions of every standard and your own certificate wording before publishing. Template licence: MIT.