# 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 | Field | Value | |---|---| | Document ID | DOC-ISMS-116 | | Version | [1.0] | | Status | [Draft / In review / Approved / Published / Superseded] | | Owner | [@isms-manager] | | Approvers/reviewers | [@ciso], [@legal-counsel], [@dpo], [@head-of-marketing] | | Last updated | YYYY-MM-DD | | Classification | Source document: [Internal]. Published sections: Public (T0) unless marked otherwise | | Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (7.4, A.5.1, A.5.12, A.5.14, A.5.34); ISO/IEC 27002:2022 | | Next scheduled review | YYYY-MM-DD (6 months, after each external audit, or at a trigger in section 6) | | Published at | [Trust centre URL], [whitepaper file name and version] | | Certificate referenced | [Standard, certificate number, certification body, expiry date] | | Answer library version | [DOC-ISMS-115 version x.y] | ### Approvals | Role | Name | Decision | Date | |---|---|---|---| | Content owner | [@isms-manager] | [Prepared] | YYYY-MM-DD | | Legal | [@legal-counsel] | [Reviewed: claims and liability] | YYYY-MM-DD | | Privacy | [@dpo] | [Reviewed: privacy sections] | YYYY-MM-DD | | Top management | [@ciso] | [Approved for publication] | YYYY-MM-DD | ### Revision history | Version | Date | Author | Change | |---|---|---|---| | 0.1 | YYYY-MM-DD | [@author] | First draft | | 1.0 *(Example)* | 2027-03-20 | [@isms-manager] | First publication after certification decision | | 1.1 *(Example)* | 2027-09-05 | [@isms-manager] | New sub-processor added, encryption section updated | ## Contents - [1. Purpose, audience and scope](#1-purpose-audience-and-scope) - [2. Publication rules](#2-publication-rules) - [3. Ownership and approval workflow](#3-ownership-and-approval-workflow) - [4. Trust centre page structure](#4-trust-centre-page-structure) - [5. Whitepaper and trust centre content](#5-whitepaper-and-trust-centre-content) - [6. Keeping the content current](#6-keeping-the-content-current) - [7. Size tiers](#7-size-tiers) - [8. Records and evidence](#8-records-and-evidence) - [9. References](#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. | Item | Covered | Notes | |---|---|---| | Products and services | [Product A, managed service B] | Name the product in each section where controls differ | | Legal entities | [Entity names] | Name the certified entity exactly as on the certificate | | Languages | [English; other interface languages if offered] | Translations are reviewed against the approved English source | | Not covered | [Products or entities outside the ISMS scope] | Say so on the page when it matters to buyers | ## 2. Publication rules ### 2.1 Writing rules | Rule ID | Rule | |---|---| | PUB-001 | State facts that are true today for the whole stated scope. Planned controls appear only in a clearly labelled roadmap block with a quarter, and only after management approval. | | PUB-002 | Use the certification wording from DOC-ISMS-097: standard and edition, certified entity, scope, certification body. Never "ISO certified", "certified by ISO" or a product certification claim. | | PUB-003 | Avoid absolute and superlative claims ("unhackable", "100 percent secure", "bank-grade", "military-grade", "fully compliant"). Describe the control instead. | | PUB-004 | Give numbers only when they are measured and you will keep them current (recovery targets, retention periods, remediation targets). Label targets as targets. | | PUB-005 | Say who operates each control when a supplier does (for example physical security of data centres operated by the cloud provider). | | PUB-006 | Every section has an owner and a review date, and is consistent with the answer library (DOC-ISMS-115). | | PUB-007 | Include a line that the content is informational and that contractual commitments are set out in the customer agreement and its security addendum (DOC-ISMS-117). | ### 2.2 What not to publish Never publish the following on the trust centre, in the whitepaper or in marketing material: | Category | Examples | Why | |---|---|---| | Reconnaissance detail | Internal hostnames, IP ranges, exact product versions of security tools, network diagrams, firewall rule sets, cloud account identifiers | Helps attackers target you | | Weakness detail | Open penetration test findings, unpatched vulnerabilities, risk register entries, audit nonconformities | Discloses exploitable gaps; share only under contract audit rights | | Credentials and keys | Any secret, token, key or certificate private part, even expired | Direct compromise risk | | Personal data | Names, e-mail addresses or phone numbers of individual staff (use role mailboxes) | Privacy and social engineering risk | | Customer information | Customer names or logos without written permission, incident details naming customers | Confidentiality obligations | | Full internal documents | Complete policies, procedures, the Statement of Applicability, full audit or penetration test reports | Gated at T2 or above (see DOC-ISMS-115 section 7) | | Unapproved claims | Certifications not held, attestations in progress described as complete, compliance with laws stated as a guarantee | Misrepresentation and contract risk | | Incident forensics | Attack paths, indicators that reveal detection gaps, ongoing investigation detail | May hinder response or legal processes | ### 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): | Document | Tier | Release condition | |---|---|---| | Statement of Applicability | T2 | Signed NDA or customer contract | | Penetration test summary letter | T2 | Signed NDA; current test only | | Policy set (selected policies) | T2 | Signed NDA | | Completed standard questionnaire (for example CAIQ v4.1) | T2 | Signed NDA | | Business continuity test summary | T2 | Signed NDA | ## 3. Ownership and approval workflow | Section of section 5 | Content owner | Approver | |---|---|---| | 5.1 Overview, 5.3 Governance | ISMS manager | CISO or top management sponsor | | 5.2 Certifications | ISMS manager | Top management, checked against DOC-ISMS-097 | | 5.4 Architecture, 5.6 Access, 5.7 Development, 5.8 Operations | Platform or engineering lead | ISMS manager | | 5.5 Data protection, 5.12 Privacy, 5.11 Sub-processors | DPO or privacy lead | Legal counsel | | 5.9 Resilience, 5.10 Incident response | ISMS manager | CISO | | 5.13 Shared responsibilities, 5.14 Contact | ISMS manager | Legal counsel | ```mermaid flowchart LR A["Change trigger (section 6)"] --> B["Owner updates source text"] B --> C["ISMS manager checks consistency with answer library"] C --> D{"New claim, number or certification wording?"} D -- Yes --> E["Legal and top management approval"] D -- No --> F["ISMS manager approval"] E --> G["Publish trust centre and regenerate whitepaper"] F --> G G --> H["Record version, URL and date in revision history"] ``` ## 4. Trust centre page structure | Block | Content | Source section | Update frequency | |---|---|---|---| | Header | One-paragraph security commitment, last updated date | 5.1 | At each review | | Certifications and attestations | Certificate cards with standard, entity, scope, CB, expiry, download of certificate | 5.2 | At each audit decision | | Security overview | Short summaries with links to whitepaper sections | 5.3 to 5.9 | At each review | | Privacy | Role (controller or processor), DPA link, data location summary | 5.12 | At each review | | Sub-processors | Current list, change notice subscription | 5.11 | At each change, before it takes effect | | Documents | Public documents and gated document request form | 2.3 | At each change | | Incident and status | Link to service status page and incident notification approach | 5.10 | Live status; text at each review | | Responsible disclosure | Security contact, disclosure policy, link to `/.well-known/security.txt` | 5.14 | At each review; security.txt before its expiry | | FAQ | Ten to twenty most asked questions from the answer library (T0 entries only) | DOC-ISMS-115 | Quarterly | ## 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. | Sub-processor *(Example)* | Purpose | Data location | |---|---|---| | [Cloud provider] | Hosting, storage, backups | [Primary region], [DR region] | | [E-mail delivery service] | Transactional e-mail | [Region] | | [Support ticketing service] | Customer support | [Region] | 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. | Area | Quillmere Analytics Ltd *(Example)* | Customer | |---|---|---| | Platform infrastructure and hosting | Operates | None | | Application security and patching | Operates | None | | Customer user accounts and roles | Provides features | Manages | | Authentication strength for customer users | Provides SSO and MFA options | Enables and enforces | | Data uploaded and its classification | Protects as customer data | Decides content and lawful basis | | Exports and API integrations | Secures the API | Protects exported data and keys | ### 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 | Trigger | Update | Deadline (*Example*) | |---|---|---| | Certification decision, surveillance or recertification result | Section 5.2 and certificate download | 5 working days | | Certificate suspended, withdrawn or expired | Remove or mark the card | Same day | | New or removed sub-processor | Section 5.11 and published list | Before the change takes effect, within the notice period | | Control change that affects a published statement | Relevant section | Before the change goes live, or same day for removals | | Significant incident | Sections 5.10 and status history; review all sections after the post-incident review | Within 10 working days of closure | | Answer library update that changes a T0 answer | Matching section or FAQ | 10 working days | | security.txt expiry date approaching | Renew the file | 30 days before expiry | | Scheduled review | Whole document and live page compared line by line | Every 6 months | 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 | Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large or multi-site: Quillmere Group (2,400 staff, 6 sites) | |---|---|---|---| | Format | One trust centre page and a 10-page whitepaper | Trust centre with gated document portal, whitepaper per product line | Group trust centre with business unit pages and site-specific certificate cards | | Certification block | One ISO/IEC 27001 certificate for the platform | ISO/IEC 27001 now; ISO/IEC 27701 card only after that certificate is issued | ISO 9001, ISO 22301 and ISO/IEC 27001 cards, each with its own scope and sites; phased ISO/IEC 27001 sites listed exactly | | Privacy content | Processor role and DPA | Processor for hospitals, controller for staff and marketing data; health sector expectations | Several entities and roles; one privacy section per legal entity | | Owner | ISMS manager (0.5 FTE) with legal support | ISMS manager, security team and DPO | CISO office with communications and legal per region | | Main risk | Page written once at launch and never updated | Privacy statements that differ between products | A business unit page claims group-wide certification | ## 8. Records and evidence | Record | Supports | Kept by | Where | Retention (*Example*) | |---|---|---|---|---| | Approved source text with version history | 7.5 | ISMS manager | [Document store] | Life of document plus 3 years | | Archived copy of each published version (page snapshot and whitepaper PDF) | 7.4, A.5.31 | ISMS manager | [Document store] | 6 years | | Approval records for new claims and certification wording | 7.4, A.5.1 | ISMS manager | [Document store] | 6 years | | Gated document request and release log | A.5.12, A.5.14 | Trust centre owner | [Trust centre tool, CRM] | 3 years | | Six-monthly live page comparison | 9.1 | ISMS manager | [Document store] | 3 years | | Sub-processor change notices sent | A.5.34, A.5.19 | Privacy lead | [Notification tool] | Contract term plus 6 years | ## 9. References | Reference | Edition and status (checked 2026-11-01) | Use | |---|---|---| | ISO/IEC 27001:2022 + Amd 1:2024 | Current; https://www.iso.org/standard/82875.html, Amd 1 https://www.iso.org/standard/88435.html | Clause 7.4; controls A.5.1, A.5.12, A.5.14, A.5.34 | | ISO/IEC 27002:2022 | Current; https://www.iso.org/standard/75652.html | Control guidance | | ISO/IEC 27701:2025 | Current; https://www.iso.org/standard/85819.html | Privacy information management (only claim if certified) | | ISO/IEC 17021-1:2015 | Current; https://www.iso.org/standard/61651.html | Certification body requirements behind certificate wording | | RFC 9116, A File Format to Aid in Security Vulnerability Disclosure | April 2022; https://www.rfc-editor.org/rfc/rfc9116 | security.txt contact file | | GDPR, Regulation (EU) 2016/679 | In force; international example | Processor role, sub-processor and breach notification context | 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.