Legal & Compliance Centre

AIAH Health Limited · Company No. 17322326

Information Security Policy

How AIAH.Health protects the confidentiality, integrity and availability of information assets.

Last updated: 7 July 2026

AIAH Health Limited handles highly sensitive women's health information. This Policy sets out the technical and organisational controls we apply to protect that information, aligned with ISO/IEC 27001 principles, NCSC guidance and the UK GDPR security principle (Article 5(1)(f)).

1. Objectives

  • Confidentiality — information is accessible only to authorised parties.
  • Integrity — information is accurate, complete and modified only in authorised ways.
  • Availability — information and services are accessible when needed.
  • Accountability — actions on systems can be traced to responsible parties.

2. Governance

Security is owned by the Board and operationally led by the Head of Engineering in partnership with the DPO. Security risks are recorded on a risk register with owners, mitigations and review dates, and reported to the Board at least quarterly.

3. Encryption

  • Encryption in transit — all traffic uses TLS 1.2 or above with modern cipher suites; HSTS is enforced.
  • Encryption at rest — AES-256 on databases, object storage, backups and secrets stores.
  • End-to-end encryption — applied to designated sensitive fields where technically feasible so that the data cannot be read by our infrastructure alone.
  • Key management — keys are stored in a managed KMS/HSM with rotation and split-knowledge dual control for the most sensitive keys.

4. Identity, access and authentication

  • Single sign-on for staff with mandatory multi-factor authentication using phishing-resistant factors where available.
  • Role-based access control with least-privilege by default; entitlements reviewed quarterly.
  • Just-in-time production access with documented approval and time-bounded elevation.
  • Immediate revocation on role change or leaver.
  • Users of the App must use strong passwords; MFA is offered and encouraged.

5. Password and secrets management

  • User passwords are stored using an industry-standard adaptive hash (e.g. Argon2/bcrypt) with per-user salts.
  • Password policy follows current NCSC guidance rather than mandatory forced rotation.
  • Staff use an approved password manager; shared credentials are prohibited.
  • Application secrets are stored in a managed secrets store; never in source control.

6. Cloud hosting

  • Production is hosted on reputable UK/EU cloud providers under Article 28 processor contracts and appropriate certifications (e.g. ISO 27001, SOC 2 Type II).
  • Infrastructure is defined as code and changes go through code review.
  • Networks apply defence-in-depth with segmented environments, WAF and DDoS protection.

7. Endpoint and device management

  • All staff devices are enrolled in a mobile device management (MDM) solution.
  • Disk encryption, screen-lock, automatic OS updates and endpoint detection and response (EDR) are enforced.
  • Devices can be remotely locked or wiped on loss or leaver.
  • USB and removable media are restricted.

8. Secure software development

  • All code changes are peer-reviewed and pass automated tests before merge.
  • Static application security testing (SAST) and dependency scanning run in CI.
  • Container images are scanned and signed.
  • Secrets scanning prevents credential leakage.
  • Threat modelling is performed for high-risk features.

9. Vulnerability management and penetration testing

  • Vulnerabilities are triaged by severity with defined remediation SLAs.
  • Independent penetration testing is performed at least annually and after major changes.
  • A responsible disclosure policy invites security researchers to report issues to [security@aiah.health].

10. Logging and monitoring

  • Application, infrastructure and access logs are centralised and protected from tampering.
  • Security-relevant events are alerted in real time to on-call staff.
  • Log retention aligns with the Data Retention Policy.

11. Business continuity and disaster recovery

  • Encrypted backups run at least daily and are periodically restored to verify integrity.
  • Recovery time and recovery point objectives (RTO/RPO) are defined for critical services.
  • A documented DR playbook is tested at least annually.

12. Incident response

Security incidents are handled under the Data Breach Response Plan. On-call rotation ensures 24/7 initial response. Post-incident reviews drive continuous improvement.

13. People security

  • Pre-employment checks appropriate to role and jurisdiction.
  • Confidentiality obligations in all employment and contractor agreements.
  • Mandatory security awareness training on induction and annually.
  • Simulated phishing exercises with targeted follow-up training.

14. Third parties

Suppliers handling personal data are subject to security due diligence, Article 28 contracts and periodic review. Sub-processors require prior approval.

15. Review

This Policy is reviewed at least annually and on any material change.