Engagement type: ISMS design and implementation, privacy compliance, risk assessment, incident response architecture
Regulatory scope: ISO/IEC 27001:2022, HIPAA/HITECH, GDPR, CCPA, NIST CSF 2.0
Analyst: Stephanie Uzama, GRC Analyst
Status: Portfolio build phase - Active
AlphaTech is a US-based healthtech SaaS company generating approximately $22M annual revenue. It operates as a business associate under HIPAA, processing protected health information for 340,000 patients across 12 US states through a clinical workflow and patient data management platform used by mid-size hospital networks and specialty clinics. The company was targeting ISO 27001:2022 certification, had confirmed GDPR exposure through a growing UK customer base, and was operating with documentation gaps that had outpaced its implementation maturity. I was engaged to design a complete ISMS from the ground up: scope it correctly, assess the risk landscape, build the policy and control framework, address privacy compliance across four regulatory regimes, and establish an incident response programme capable of meeting HIPAA breach notification timelines.
I approached this as an end-to-end ISMS build, not a document production exercise. Every decision I made connected to a specific regulatory requirement, a risk register entry, or an audit evidence need. I worked across six domains simultaneously: governance, risk, controls, privacy, incident response, and vendor management.
The methodology I applied was ISO 27001:2022-led, with HIPAA as the primary operational constraint and GDPR as a supplementary layer for UK data subjects. I used NIST CSF 2.0 as a maturity reference to identify implementation gaps that the ISO standard does not surface on its own. Every document I built was mapped to at least one clause, article, or control reference. Nothing in the portfolio is unmapped.
I structured the portfolio as a working compliance system rather than a document library. Risks link to controls. Controls link to policies. Policies link to regulatory obligations. Evidence links to controls. A recruiter or auditor can trace any single risk from identification through treatment to proof of control effectiveness without leaving the system.
| Deliverable | What It Achieved |
|---|---|
| ISMS Clause 4 Context Analysis (V2.0) | Defined the ISMS scope boundary with explicit justification for legacy warehouse exclusion. Identified the five primary internal vulnerability drivers and three primary external threats. |
| Information Security Policy (V3.0) | Set the LOW risk appetite position, established TLS 1.2+ and FIPS 140-2 as mandatory encryption standards, and created the governance framework for all downstream policies. |
| Risk Register (V3.0, 36 entries) | Completed the organisation's first fully assessed risk register. Identified four material gaps in the original register including two Score 20 HIGH risks that had no active treatment. Cross-referenced duplicate entries across the ISMS and HR Portal registers. |
| Risk Assessment Report (V1.0) | Documented methodology, register quality findings, and five priority remediation actions ranked by risk score, regulatory consequence, and implementation urgency. |
| Access Control Suite (6 documents) | Built a complete identity governance architecture covering role-based access, SoD conflicts, JML procedures, privileged access controls, quarterly review process, and vendor access governance. |
| Incident Response Suite (9 documents) | Built a nine-document IR programme with AlphaTech-specific incident categorisation, severity matrix, HIPAA breach notification pathway, digital forensics procedures, and playbook framework. |
| Privacy Compliance Package (DPIA, ROPA, Data Retention Schedule, Privacy Policy) | Addressed GDPR Article 30 (ROPA), Article 35 (DPIA for AI analytics processing), Article 5(1)(e) (storage limitation), and CCPA deletion rights. Documented cross-border transfer mechanisms for UK patient data. |
| Notion ISMS Portfolio | Structured all documents as an operational compliance system with five live databases (Risk Register, Policy Register, Control Library, Vendor Register, Control Testing Tracker) connected by logic, not just navigation. |
The original ISMS documentation had not formally committed to a risk appetite level. I set it at LOW and documented the reasoning explicitly in the Clause 4 context analysis and the Information Security Objectives plan. The reasoning was specific to AlphaTech's situation: HIPAA penalty exposure reaches USD 1.9M per violation category, AlphaTech processes PHI for 340,000 patients, and its covered entity clients carry their own regulatory liability that they would transfer back to AlphaTech through contract terms if a breach occurred. A MEDIUM appetite would have allowed several HIGH risks to be accepted without treatment. Under a LOW appetite, those same risks require active Modify or Avoid action. That distinction has direct consequences for what the ISMS is legally and contractually required to do.