DRAFT — REQUIRES REVIEW BY EXTERNAL ISO 27001 CONSULTANT AND SIGN-OFF BY BRITIAI CTO BEFORE USE IN BID OR AUDIT.
ISO/IEC 27001:2022 — Policy Framework
Document ID: ISO05 Version: 0.1 (Draft) Date: 15 June 2026 Owner: BritiAI CISO (interim: CTO) Purpose: Enumerate the policy set required to satisfy ISO/IEC 27001:2022 Clauses 5.2, 7.5, and Annex A control families, including NHS-specific additions for the SBS10523 Healthcare AI Solutions Framework.
1. Policy hierarchy
BritiAI operates a three-tier documentation hierarchy:
- Policies — high-level statements of intent, approved by the Board, reviewed annually.
- Standards — mandatory technical and procedural requirements derived from policy, approved by the CTO.
- Procedures / Runbooks — step-by-step operational documents, approved by the relevant function head.
Each policy is owned by a named role, references the Annex A controls it satisfies, lists exceptions and review cadence, and is published in the ISMS document control register.
2. Required policies
2.1 Information Security Policy (top-level)
Owner: CTO. Annex A: A.5.1. The apex policy of the ISMS. Establishes management commitment per Clause 5.1, defines security objectives, allocates accountability, mandates compliance with applicable law (UK GDPR, DPA 2018, NIS Regulations 2018, NHS contractual obligations), and asserts BritiAI’s intent to maintain ISO/IEC 27001:2022 certification. Approved by the Board, communicated to all personnel on induction and annually thereafter, and reviewed at each Management Review.
2.2 Access Control Policy
Owner: Head of Engineering. Annex A: A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, A.8.5. Defines the principles of least privilege, need-to-know, role-based and attribute-based access control, segregation of duties, joiner-mover-leaver (JML) processes, and recertification cycles. Mandates multi-factor authentication for all corporate and production access, with FIDO2 hardware tokens for privileged roles. Establishes that no Votee or Beever identity is provisioned into NHS-bearing environments, with quarterly access reviews verifying conformance.
2.3 Cryptography Policy
Owner: Head of Engineering. Annex A: A.8.24. Specifies approved algorithms (AES-256-GCM for data at rest; TLS 1.2 minimum, TLS 1.3 preferred for data in transit; SHA-256+ for hashing; Ed25519/ECDSA P-256+ for signing). Mandates customer-managed keys (CMK) for NHS workloads with key rotation at least annually and on personnel change for key custodians. Prohibits proprietary or deprecated algorithms (DES, RC4, MD5, SHA-1). Defines key custody, escrow, and destruction procedures aligned to A.8.10.
2.4 Acceptable Use Policy (AUP)
Owner: Head of People. Annex A: A.5.10, A.6.7. Defines acceptable and prohibited uses of BritiAI information assets, including corporate email, collaboration tools, cloud accounts, code repositories, and AI tools. Prohibits storage of customer or NHS data on personal devices, personal cloud accounts, or unmanaged generative AI services. Sets out the remote-working baseline, clear-screen requirement, and incident reporting obligations. Acknowledged on induction and annually.
2.5 Asset Management Policy
Owner: Head of Ops. Annex A: A.5.9, A.5.11, A.7.8, A.7.9, A.7.10, A.7.14. Defines the lifecycle of information assets (information, software, hardware, services, intangibles) and the maintenance of the central asset register. Covers acquisition, classification, labelling, custody, transfer, return on termination, and secure disposal with certified-destruction records. Endpoint devices are enrolled in MDM as a precondition of issue.
2.6 Supplier Security Policy (critical for Votee/Beever relationship)
Owner: Head of Ops, with Legal. Annex A: A.5.19, A.5.20, A.5.21, A.5.22, A.5.23, A.8.30. Governs the security obligations of all third-party suppliers including BritiAI’s affiliated sub-processors Votee Limited (Hong Kong) and Beever (Toronto). Establishes a tiered supplier risk classification (Tier 1: NHS-data-bearing suppliers; Tier 2: production-system suppliers; Tier 3: corporate suppliers) and mandates a security assessment proportional to tier. Tier 1 and Tier 2 suppliers must execute an ISO 27001-aligned security schedule, a UK GDPR Article 28 DPA with IDTA/SCC for international transfers, sub-processor approval workflow, right-to-audit clauses, and incident notification within 24 hours. Specifies that Votee and Beever are contractually prohibited from processing NHS data and that this prohibition is enforced architecturally through tenant isolation and IAM. Annual reviews and continuous monitoring (cloud security posture, breach notifications, certification status) are mandatory.
2.7 Incident Management Policy
Owner: CISO. Annex A: A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.6.8. Defines the end-to-end incident lifecycle: preparation, detection, triage, containment, eradication, recovery, post-incident review, and evidence preservation. Sets severity classifications (SEV-1 to SEV-4) and corresponding response SLAs. Mandates notification to the ICO within 72 hours where personal data is implicated, to NHS customers per contractual SLA, and to affected data subjects where required. Establishes the on-call rota, war-room procedure, communications protocol, and forensic readiness practices including chain-of-custody for digital evidence.
2.8 Business Continuity Policy
Owner: Head of Ops. Annex A: A.5.29, A.5.30, A.8.13, A.8.14. Sets the framework for business continuity management (BCM) and ICT disaster recovery (DR). Defines Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets per service tier — NHS-facing services target RTO 4 hours / RPO 1 hour. Mandates annual BCP exercises and at least one DR failover test per year, with documented lessons learned feeding the corrective action register. Backup architecture is immutable, encrypted, and tested for restorability quarterly.
2.9 Information Classification and Handling Policy
Owner: DPO. Annex A: A.5.12, A.5.13, A.5.14, A.5.33, A.5.34, A.8.11, A.8.12. Defines four classification tiers — Public, Internal, Confidential, Restricted — with NHS Patient-Identifiable Data and UK GDPR Special Category Data treated as Restricted. Specifies labelling, handling, storage, transmission, retention, and deletion requirements per tier. Mandates data masking and pseudonymisation for development and analytics use, and prohibits use of Restricted data in non-production environments. Addresses data leakage prevention controls in M365/Google tenants.
2.10 Change Management Policy
Owner: Head of Engineering. Annex A: A.8.32, A.5.37. Governs changes to production systems, infrastructure, and security configurations. All changes follow a documented workflow with risk assessment, peer review, approval gate, rollback plan, and post-change verification. Emergency changes follow an expedited path with retrospective review. Infrastructure-as-code is the default delivery mechanism; out-of-band changes require explicit CAB-equivalent approval.
2.11 Secure Development Policy
Owner: Head of Engineering. Annex A: A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.31, A.8.33. Establishes the secure development lifecycle: security requirements gathering, threat modelling, secure coding standards (OWASP-aligned), peer review with security checklist, SAST/DAST/SCA in CI, dependency provenance and SBOM generation, separation of development/test/production environments, and prohibition of production data in non-prod. Includes AI-specific additions: model evaluation for safety and bias, prompt-injection defences, and red-team testing of model-integrated features. Outsourced development by Votee and Beever follows the same standards under A.8.30 with code review by BritiAI personnel.
2.12 Cryptographic Key Management Standard (supporting Cryptography Policy)
Owner: Head of Engineering. Annex A: A.8.24. Operational detail of key generation, distribution, custody, rotation, revocation, and destruction. Tracks each key in a key inventory with owner, purpose, algorithm, length, and expiry.
2.13 Logging and Monitoring Standard
Owner: CISO. Annex A: A.8.15, A.8.16, A.8.17, A.5.7. Defines what is logged (authentication, authorisation, privileged actions, data access for Restricted data, security events), retention (12 months hot, 6 years cold for NHS contexts), integrity protection (append-only/WORM), monitoring use cases, and alerting thresholds. Includes threat intelligence feed ingestion (NCSC CiSP and commercial sources).
2.14 Vulnerability and Patch Management Standard
Owner: CISO. Annex A: A.8.8. Establishes scanning cadence, patch SLAs by CVSS severity (Critical: 7 days, High: 14 days, Medium: 30 days, Low: 90 days), exception process with compensating controls, and reporting to Management Review.
2.15 Network Security Standard
Owner: Head of Engineering. Annex A: A.8.20, A.8.21, A.8.22, A.8.23. Mandates default-deny network policy, segmentation between production/non-production and between NHS and non-NHS tenancies, TLS everywhere, web application firewalling, DDoS protection, and secure web gateway for egress filtering.
2.16 Physical Security Standard
Owner: Head of Ops. Annex A: A.7.1–A.7.14. Defines office access controls, visitor management, clear-desk and clear-screen requirements, secure rooms for sensitive work, environmental controls, and disposal certification.
2.17 HR Security Standard
Owner: Head of People. Annex A: A.6.1–A.6.6. Sets pre-employment screening (right to work, references, criminal record check where lawful, BPSS-equivalent for NHS-facing personnel), security clauses in employment contracts and contractor agreements, induction security training, role-specific competence requirements, and leaver obligations including access revocation and asset return.
2.18 AI Risk and Safety Policy (NHS-specific addition)
Owner: Head of Engineering, with DPO. Aligns with intended ISO/IEC 42001 adoption. Establishes governance over the AI lifecycle including data sourcing, model training, evaluation, deployment, monitoring, and decommissioning. Mandates human oversight for any model output influencing clinical or care decisions, bias and fairness evaluation, model cards, and incident reporting for AI-specific failure modes (hallucination, prompt injection, jailbreak, model drift).
2.19 Data Protection and Privacy Policy (NHS-specific addition)
Owner: DPO. Annex A: A.5.34. Operationalises UK GDPR and DPA 2018 obligations: lawful basis, ROPA maintenance, DPIA process, data subject rights, international transfers, breach notification, and DPO function. Includes specific NHS provisions for Caldicott Principles, the Common Law Duty of Confidentiality, and the NHS DSPT.
2.20 Compliance Policy
Owner: Legal. Annex A: A.5.31, A.5.32, A.5.36. Identifies applicable legal, regulatory, and contractual obligations and the controls that satisfy them. Maintained as a live register, reviewed quarterly.
3. Policy lifecycle
All policies follow a documented lifecycle: draft → review → approval → publication → communication → operation → review → revision or retirement. Annual review is mandatory; out-of-cycle review is triggered by material change, incident, or audit finding. Version history, approver, and effective date are recorded in the document control register.
4. Communication and acknowledgement
Policies are published in the BritiAI knowledge base, communicated via induction, and acknowledged annually by all personnel and applicable contractors. Targeted briefings accompany substantive change.
5. Mapping to Annex A
A control-to-policy mapping table is maintained as an appendix to the SoA (ISO02), ensuring every Applicable Annex A control has at least one owning policy.
End of document.