The technological theme holds 34 controls — second only to the organizational 37, and more than a third of the 93. It is also the theme where a company already building and running healthcare SaaS has the most already in place.
That is what makes it different. Multi-factor authentication, disk encryption, dependency scanning, tests in CI — any competent engineering organisation is already doing these. The time an ISMS project consumes here goes into a different task: reconciling what you do against what the standard asks, and making it retrievable as evidence.
This article groups the 34 into six clusters and covers what to implement and what to record, in the context of healthcare SaaS. For the overall map see Annex A 2022: 93 Controls Across Four Themes.
Disclaimer: This article is general information. Control titles and requirement text live in the standard; we describe intent in our own words rather than quoting. Base decisions on ISO/IEC 27001 (JIS Q 27001) and the publications of the accreditation and certification bodies.
Six Clusters Cover the 34
| Cluster | What it is for | Main outputs |
|---|---|---|
| ① Access control and authentication | Technically enforce who can reach what | Permission matrix, privileged ID register, MFA evidence, access review records, endpoint configuration |
| ② Vulnerabilities and configuration | Close known holes; detect configuration drift | Vulnerability procedure, scan results and treatment records, configuration baselines, software installation rules |
| ③ Data protection lifecycle | Protect information through storage, use, copying, deletion | Cryptography policy and key management, backup design and recovery test records, deletion and masking procedures |
| ④ Logging and monitoring | Be able to explain who did what, when | Logging policy, retention definitions, alerting design, clock synchronisation, review records |
| ⑤ Networks | Control paths and reachability | Network diagrams, segregation design, connectivity inventory, filtering policy |
| ⑥ Secure development | Build without introducing vulnerabilities | Development lifecycle procedure, secure coding standards, test records, environment separation, change records |
For healthcare companies the weight falls on ①, ④, and ⑥. When medical information is involved, customers ask most concretely about who can access it, who did access it, and how the system was built.
Access Control and Authentication: The Basis of Accountability
This cluster covers user endpoint devices, privileged access rights, information access restriction, access to source code, secure authentication, and use of privileged utility programs. Policy sits in the organizational theme; here it is implementation.
Privileged IDs are the focus. Accounts that reach the production database, cloud console administrator rights, operational consoles with cross-tenant access. Because they are not needed daily, this design makes the story simple:
- Not permanently granted — requested, approved, and granted temporarily
- Grant and return recorded automatically
- Privileged operation logs reviewed periodically by someone without those rights
- No shared accounts detached from individuals (or, where unavoidable, usage records that identify the individual)
Treat access to customer tenants separately. Operations staff being able to enter a hospital's production data is necessary for support and is the thing hospitals scrutinise hardest. Recording who entered which institution's data, when, and for what purpose — and being able to disclose that to the customer — is sometimes a contractual condition. See ISMS for Healthcare SaaS: Multi-Tenant Risk.
Access to source code is easily overlooked: repository permissions, forking, revocation for leavers, and the credentials handed to CI/CD. Source code contains connection details and business logic, so it belongs in the asset register.
If you expose system capability to AI agents or over MCP, the same framework applies to that permission design — see MCP Permission Design.
Vulnerabilities and Configuration: Cadence and Records
Malware protection, technical vulnerability management, configuration management, installation of software on operational systems, and capacity management.
Technical vulnerability management is the classic subject of concrete audit questions. What is required is not the absence of vulnerabilities but a mechanism to receive information, assess your exposure, decide, act, and record.
| Stage | Typical implementation | Record to keep |
|---|---|---|
| Intake | Dependency scanning, provider advisories, JPCERT/CC alerts | Evidence of the periodic review |
| Assessment | Do we run the affected version? Is it externally reachable? How sensitive is the data? | The judgement and its basis |
| Decision | Fix now / next release / mitigate with a workaround / accept | Decision and approver |
| Action | Patch, upgrade, configuration change | Date and scope |
| Verification | Re-scan, functional check | Result |
Record the decisions not to act, too. Deferring a medium-severity issue in an internally reachable tool to the next scheduled update is reasonable — but it is a decision, not neglect, and it needs a record. A blank here reads as "unmanaged."
Vulnerabilities in VPN and perimeter devices have been a real entry point for incidents in healthcare; see Managing VPN Device Vulnerabilities.
Configuration management asks for baselines: a defined "correct" configuration for servers, cloud resources, and endpoints, plus a way to detect drift. If you manage infrastructure as code with drift detection, the mechanism itself is the answer. Anywhere production is still changed by hand is the weak point.
The Data Protection Lifecycle
Deletion of information, data masking, data leakage prevention, use of cryptography, backup, redundancy, and protection of test information. This cluster overlaps heavily with Japan's three-ministry guidelines.
For cryptography, what is required is less the use of encryption than policy and key management: which method for which information, where keys are generated, how they are stored, when they rotate, who can access them. Managed key services make this easy to evidence through configuration and permissions. "We use TLS" answers half the requirement.
For backup and redundancy, the question is the recovery test record rather than the design. Declaring an RPO and RTO without ever restoring is a finding. Restore once a year, measure how long it took, keep the record — it doubles as material for hospital proposals.
Protection of test information may be the heaviest item in practice for healthcare SaaS. Copying production patient data into a staging environment is hard to justify under either the standard or the guidelines. The options:
| Approach | What it is | Watch for |
|---|---|---|
| Synthetic data | Generated from the specification, no real data | Safest, but hard to reproduce the edge cases real data produces |
| Masking / pseudonymisation | Identifiers replaced, statistical properties retained | Reversibility, and residual indirect identifiability |
| Limited use of production data | Purpose-bounded (e.g. incident investigation), time- and permission-limited | Formalise approval and erasure, and record both |
In reality you combine all three. What matters is documenting which applies when. "Synthetic by default; production data only for incident investigation, under approval, erased on completion" is a defensible position.
Deletion of information is also easy to forget: erasing medical information when a customer terminates, deleting logs past retention, wiping devices at exit. Where you have contracted an erasure deadline, you need both the capability and the record.
Logging and Monitoring: Collection Is Not the Test
Logging, monitoring activities, clock synchronisation, and protection of information systems during audit testing.
Technically, most organisations already collect logs. Three things go wrong.
1. No policy on what to collect. "Everything we can" inflates cost and buries what matters. At minimum, state these explicitly:
- Authentication successes and failures, especially for privileged accounts
- Granting, changing, and revoking permissions
- Access to medical information — read, update, export, delete
- Administrative operations: configuration changes, deployments, direct database work
- Disabling or altering security functions
2. No defined retention. Incidents surface late. Three months of retention cannot trace an intrusion from six months ago. For medical information access logs, contracts or guidelines may set a period, so decide in the order contractual requirement → retention → storage design.
3. Nobody reviews them. The most common gap. Collected-but-unwatched logs do not function as a detective control. Not everything needs human eyes: automated alerting plus periodic sampled review is enough. A monthly one-page "alerts raised and how they were handled" satisfies the record.
Clock synchronisation is dull and important. Correlating logs across systems fails when clocks disagree. Confirm NTP and a consistent timezone, and record the configuration.
See Shared Responsibility in AI EMR Security Design and The Three-Ministry Guidelines for how far your side of the logging boundary should extend.
Networks and Secure Development
Networks
Network security, security of network services, segregation of networks, and web filtering. In cloud architectures the explanation centres on VPC and subnet design, security group configuration, an inventory of public endpoints, and whether a WAF is in place.
Keeping the network diagram current is the most efficient preparation you can do: the same diagram serves both the audit and customer security questionnaires. Show external touchpoints (ingress from the internet, egress to third-party APIs), where medical information is stored, and the path for administrative access.
For multi-tenant SaaS, expect to be asked whether tenant isolation is enforced at the network layer or the application layer. If it is application-level tenant scoping alone, you will need tests demonstrating the implementation is correct.
Secure development
The largest sub-group: development lifecycle, application security requirements, secure architecture and engineering principles, secure coding, security testing in development and acceptance, outsourced development, separation of development/test/production, and change management.
If you already have a development process, the answer is restating it in the standard's vocabulary, not building it anew.
| Requirement | Usually already running | Usually still needed |
|---|---|---|
| A defined development lifecycle | Git flow, mandatory PR review | Documenting and approving it |
| Security requirements defined | Handled implicitly inside functional requirements | An explicit security requirements field at specification time |
| Secure coding | Linters, static analysis, review | Documented standards and training records for new joiners |
| Testing at development and acceptance | Automated tests in CI | Security-oriented test cases and records of running them |
| Environment separation | dev / stg / prod split | Assurance that production data does not flow downward, and verification of it |
| Change management | PR approval, release procedure | A post-hoc approval path for emergency changes |
| Outsourced development | Contract and acceptance | Security requirements on the supplier and security verification of deliverables |
The right-hand column is the actual work — and it is smaller than it looks when the left-hand column already exists. See Security by Design for Medical Systems.
If you are shipping generative-AI features, add concerns that do not fit classical vulnerability taxonomies — prompt injection, medical information leaking into training data. See Generative AI in Healthcare: Legal and Security Guide.
Conclusion
- The 34 converge on six clusters; in healthcare the weight is on access control, logging, and secure development
- Stop granting privileged IDs permanently — move to request, approve, record, and log customer-tenant access separately
- Vulnerability management is judged on the assess-decide-act-record mechanism, not on having no vulnerabilities; record decisions not to act
- Backups are judged on the recovery test record; once a year is enough, but it must exist
- Document when you use synthetic data, masking, or limited production data. Unconditional copies of production are hard to defend
- For logs, retention and review matter more than collection — alerting plus sampled review, recorded monthly on one page
- For secure development, restate the process you already run in the standard's language rather than inventing one
Pottech supports ISMS certification with a focus on healthcare. The technological theme is won or lost on translating real engineering practice into documents and records. We work from an understanding of how software is actually built and connect what you already do to what the standard asks.
See ISMS Certification Support for scope and pricing, or contact us.
See also What Is an ISMS? A Complete Guide for Healthcare Companies, Writing the Statement of Applicability, and Reading the 37 Organizational Controls.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- ISO/IEC 27002 Information security controls | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Security Alerts | JPCERT Coordination Center
- Information-technology Promotion Agency (IPA)
Note: interpretation of controls and the acceptability of exclusions can change with revisions to the standard and the practices of certification bodies.