How do healthcare organizations and health tech vendors use ISO 27001?
A hospital, payer or software vendor usually meets ISO 27001 because a customer, contract or regulator asks for it. Start by understanding what the request actually certifies. ISO does not certify organizations and neither does DeployOpen; an accredited certification body issues the certificate after an independent audit against ISO/IEC 27001:2022. The health-specific control guidance sits in ISO 27799:2025, *Health informatics: Information security controls in health based on ISO/IEC 27002*, which builds on ISO/IEC 27002:2022 and replaced ISO 27799:2016. ISO 27799 is guidance for the Annex A controls, not a separate certification, so the certificate still rests on ISO/IEC 27001.
The scope statement decides how much of the organization the certificate covers. For a provider, that usually means deciding whether the scope includes the electronic health record system, the medical devices and other digital equipment on clinical premises, and remote or virtual care services, since ISO 27799:2025 covers all of these care settings. For a vendor, the scope is the product platform, hosting environment, support operations and any sub-processors. The HIPAA position matters as much as the scope: a cloud service provider that handles electronic protected health information for a covered entity is a business associate even if it holds only encrypted data without the key, and business associates are directly liable to OCR for Security Rule failures. Confirm with counsel which entities in the scope are business associates before drafting the statement of applicability.
ISO 27001 does not discharge HIPAA obligations by itself. The HHS guidance on HIPAA and cloud computing explains the business associate duties that a certificate does not replace, such as business associate agreements and documented safeguards mapped to 45 CFR 164.302. Map each Security Rule requirement to the controls in your Statement of Applicability so an assessor and a customer can trace both frameworks to the same evidence. Ask any certification body whether it will review health-specific controls in its audit plan, and ask customers which of the two obligations they actually need evidenced.
How to scope ISO 27001 for EHR, medical devices and remote care
A hospital or provider network usually sets its ISMS boundary around the clinical and administrative functions that handle patient information, not around the legal entity alone. The boundary normally includes the EHR as deployed for the organization, the identity platform that controls clinician access, the integration engine that moves messages between systems, network segments that carry clinical traffic, and the staff and sites that use them. Scope decisions belong to the organization, and the reasoning should be written down so an auditor can follow it.
- Clinical systems: List the EHR, laboratory and imaging interfaces, pharmacy systems and clinical document stores that hold or transmit patient data, and state which are inside the boundary.
- Sites and departments: Name each hospital, clinic and shared service center, and explain any site left out.
- Shared networks: Record how clinical VLANs, Wi-Fi and remote access connect to the in-scope systems.
- Third-party hosted systems: Where a vendor runs the EHR, document the shared responsibility split and the vendor's own certificate or assurance evidence.
- Statement of Applicability: Justify every Annex A control excluded, such as a physical control for a site that is not in scope.
Before finalizing scope, confirm with your certification body how it will treat vendor-hosted systems and medical devices on your network.
A health software vendor that hosts an EHR for customer organizations scopes its ISMS around the service it delivers. The boundary usually covers the production and recovery environments, the application and its databases, the administrative tooling used to access customer tenants, the people and suppliers who operate them, and the support processes that touch patient data. Customer-owned clinical sites normally sit outside the boundary, but the vendor's obligations to those sites should appear in its contracts and controls.
- Service boundary: Define the hosted EHR platform, its environments, and the management plane that reaches customer data.
- Cloud infrastructure: Record which cloud accounts, regions and managed services are included, and attach the provider's certificates as supporting evidence without treating them as your own certification.
- Support access: Bring privileged support and break-glass access inside the boundary, since these paths expose patient data.
- Subprocessors: Identify hosting, backup, logging and messaging suppliers that handle data and document how each is controlled.
- Customer responsibilities: State which controls customers must run, such as their own user accounts and local device management.
Confirm that the scope statement on your certificate matches the service customers actually buy, since buyers compare the two during due diligence.
A maker of medical device software needs to decide whether the ISMS covers the software product, the development and release environment, or the whole company. For most vendors, the ISMS boundary includes the engineering systems that build, test and release the software, the update and vulnerability handling processes, and any cloud services that receive device data. The regulatory file for the device is a separate body of work, so the ISMS should reference it rather than duplicate it.
- Development environment: Include source control, build pipelines, signing keys and test infrastructure, since these control what reaches devices.
- Field and update channels: Document how patches and updates are distributed, authenticated and rolled back.
- Device data services: Where telemetry or remote monitoring data flows to a vendor cloud, bring those services and their storage inside scope.
- Vulnerability intake: Describe how security reports about deployed devices are received, triaged and communicated.
- Interfaces to ISO 27799:2025: Use the health controls and guidance as a reference for device-related controls, and record where you adopted or excluded them.
Ask your regulatory and quality teams to review the scope so product security obligations stay consistent across the ISMS and the device file.
A remote or virtual care provider handles patient data outside the traditional clinic, through telehealth platforms, home monitoring, messaging and clinician devices. ISO 27799:2025 applies to all care settings, including remote or virtual care, so the ISMS boundary has to follow patient data wherever it travels. Scope should include the platforms patients and clinicians use, the endpoints clinicians connect from, and the cloud services that carry sessions and records.
- Care platforms: Include the video visit tool, scheduling, messaging and any patient portal that handles health information.
- Clinician endpoints: Decide whether personal or contractor devices are in scope, and document the controls required before they connect.
- Home-based devices: Where monitoring devices send data to the provider, define the ingestion path and its storage as in scope.
- Third-party telehealth services: Record which external platforms are used, their assurance evidence and their contractual terms.
- Location and staffing: Address clinicians working from several locations and explain how remote access is controlled and logged.
Check that the Statement of Applicability justifies any physical controls excluded for clinicians working from home, since assessors look closely at those exclusions.
How ISO 27001 relates to HIPAA obligations for US business associates
US business associates that handle electronic protected health information carry Security Rule duties directly, and an ISO 27001 certificate does not discharge them. The cards below set out the status question, the regulator's reach, the gap between the two frameworks and the mapping work that has to be done and checked.
Cloud providers can be business associates
A cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity or business associate is a business associate under HHS guidance. This holds even when the provider stores only encrypted ePHI and never holds the encryption key. For an ISO 27001 scope, the first decision is whether your hosting, backup or support platform falls into this role, and whether the contract and the scope statement reflect that. Confirm the answer with counsel rather than assuming it from the certificate.
Security Rule standards apply directly
Business associates must comply with the standards and implementation specifications of the HIPAA Security Rule in 45 CFR 164.302, and they are directly liable to OCR for Security Rule failures. A customer's covered entity contract does not move that liability away from you. Map each Security Rule standard to the ISMS process, Annex A control and evidence that covers it, and record where a standard has no ISO 27001 counterpart, such as the workforce and documentation requirements that must be written in HIPAA terms.
Certification is not a HIPAA attestation
An ISO 27001 certificate shows that an accredited certification body found the management system conformed to the standard for a defined scope. It is not a HIPAA attestation, and it does not satisfy the Security Rule by itself. Expect a customer or OCR inquiry to ask for risk analysis, policies addressing ePHI, workforce training records and breach procedures in HIPAA terms. Ask your certification body to confirm in writing what its report does and does not cover.
Mapping must be built and validated
A mapping between ISO 27001 Annex A and the Security Rule should be prepared by the organization, with an implementation partner if needed, and then validated by a qualified reviewer such as counsel or an independent assessor. Record the mapping in the Statement of Applicability or a separate crosswalk, note every gap, and link each entry to evidence. Treat a crosswalk as a working document that needs review each time either framework or your scope changes, not as a finished deliverable.
Enforcement and pending changes
OCR settled a HIPAA investigation with MMG Fusion on March 5, 2026, a reminder that the regulator enforces against business associates as well as covered entities. A proposed update to the Security Rule was published on 6 January 2025 and remains pending, so its final text may change obligations that a mapping built today would need to reflect. Check the Federal Register for the current status before setting a mapping's review date.
How the ISO 27001 certification process runs for a health organization
The sequence moves from a defined scope and risk assessment to a Statement of Applicability, internal checks and management review, then two certification audits and a surveillance cycle, with each phase leaving a specific record that an independent certification body can test.
Define the ISMS scope and context
The organization decides which entities, sites, systems and health services fall inside the information security management system, including whether EHR platforms, medical device software and remote or virtual care services are covered. Leadership records the internal and external issues and the interested parties, such as patients, payers, regulators and contracting hospitals, whose requirements apply. Clause 4 of the standard requires this context to be documented. The step closes with a written scope statement approved by top management. Health tech vendors should confirm early whether their hosted environments, customer-deployed components and support access sit inside that boundary.
Assess information security risks
The team identifies assets such as clinical records, interfaces, medical device software, backups and administrator accounts, then rates the threats and vulnerabilities that could affect confidentiality, integrity and availability. Risk owners are named for each risk, and the method is documented under the risk assessment process in clause 6.1.2. ISO/IEC 27005:2022 is a common reference for this method. The step closes with a risk assessment record that shows how each risk was scored and who accepted it. Organizations with existing HIPAA risk analyses can use that work as an input, but should confirm that it covers the ISMS scope and the criteria the standard requires.
Prepare the risk treatment plan
For each risk that needs action, the organization chooses a treatment such as reducing, avoiding, transferring or accepting it, then assigns an owner and a target state. Where a risk is reduced, the team selects controls from Annex A, which includes the health-specific guidance in ISO 27799:2025 as an implementation reference rather than a separate certifiable set. The output is a risk treatment plan linked to the risk register. The plan should show gaps between existing and intended controls so that the assessor can trace each decision. Confirm with your certification body how it expects the plan to reference health sector guidance.
Produce the Statement of Applicability
The Statement of Applicability lists all 93 Annex A controls, states which ones apply and why, and records the controls that do not apply with a justification. Each applicable control is linked to its implementation status and to the evidence that shows it operates, such as access reviews, backup restore tests or vendor assessments. Clause 6.1.3 d) requires this document. The step closes when the SoA is approved and matches the risk treatment plan. Assessors use it as the map of the whole ISMS, so inconsistencies between the SoA and the scope or risk records are a frequent source of findings.
Run internal audit and management review
Before the certification body arrives, an internal auditor independent of the controls reviews the ISMS against the standard and the organization's own procedures, and records nonconformities and observations. Top management then reviews performance, audit results, risk changes and improvement actions in a management review meeting. The internal audit report and management review minutes are the outputs. Both are evidence that the organization checks its own system. Organizations often use an external consultant to support this step, but the internal audit must be carried out and owned by the organization, and the consultant should not also act as the certification body.
Complete the Stage 1 documentation review
The certification body reviews the documented ISMS, including the scope, policies, risk assessment, risk treatment plan and Statement of Applicability, to judge whether the system is ready for a detailed audit. It may also confirm the site or service boundaries and the readiness of the people responsible. The output is a Stage 1 report that lists any gaps to close before Stage 2. Gaps raised here should be corrected and the records updated before the main audit. Certification bodies accredited to ISO/IEC 17021-1 and ISO/IEC 27006-1 apply those requirements to the audit, and IAF MD 29:2024 set 31 March 2026 as the date by which they had to apply ISO/IEC 27006-1 to all clients.
Pass the Stage 2 certification audit
The assessor tests whether the ISMS is implemented and operating in practice. It samples clinical systems, access records, incident logs, vendor files, device inventories and training records, and interviews staff in clinical, IT and administrative roles. Findings are classed as nonconformities or observations, and major nonconformities must be closed before a certificate is issued. The outputs are the audit findings report and, when conditions are met, the certificate. Only the accredited certification body issues the certificate. Organizations should confirm the certificate scope wording with the body before publication.
Maintain the certificate through surveillance
Under ISO/IEC 17021-1, a certification cycle lasts three years, and the certification body must audit the client at least once in every calendar year, through surveillance audits and then recertification. The organization keeps running internal audits, management reviews and corrective actions between visits, and it must report significant changes such as new EHR modules, new device types or changes to the scope. Each surveillance audit produces its own findings. Organizations that certified to the 2013 edition had to complete the transition under IAF MD 26:2023 before 31 October 2025, so any older certificate should have been reissued against the 2022 edition.
What must be in place before the certification audit
A certification body will test whether the ISMS is documented, risk-based and operating before it issues a certificate. The cards below cover the items an auditor expects to see for a healthcare organization or health tech vendor, and each one says what to check before the audit plan arrives.
Documented ISMS scope
The scope statement must name the EHR systems, device software, clinical sites and remote or virtual care services that fall inside the ISMS, along with the facilities and third parties that support them. Auditors compare the scope against the network, asset inventory and product list, so any system that touches patient data but sits outside the statement invites a nonconformity. Check that every exclusion is justified in writing and that the scope matches what the organization actually runs.
Risk assessment and treatment plan
Clauses 6.1.2 and 6.1.3 require a repeatable method for identifying information security risks and a documented plan for treating them. For healthcare, risks to clinical availability, medication data integrity and medical device software deserve explicit entries. Confirm that the method is consistently applied, that owners are named for each risk, and that accepted risks carry a sign-off from management.
Statement of Applicability
The Statement of Applicability records which Annex A controls the organization applies, which it excludes and why, and where each implemented control is evidenced. It is the document auditors use to trace from risk to control to evidence, so it must agree with the risk treatment plan. Check that each justification for exclusion is specific to the organization and that the referenced policies and records exist and are current.
Clinical access reviews
Auditors look for periodic reviews showing that access to EHR records, prescribing functions and device administration matches current job roles. Reviews should cover leavers, role changes and shared or emergency accounts, with the reviewer's name and the date recorded. Pull a sample of several recent reviews and confirm that removed access actually disappeared from the system, not only from the review record.
Vendor and hosting oversight
Hosting providers, EHR vendors, cloud platforms and device manufacturers that handle patient data are suppliers within the ISMS. Auditors expect a current register of these suppliers, security terms in contracts, and evidence that each one was reviewed against its own assurance reports. Where a supplier handles ePHI for a US covered entity, confirm that a business associate agreement is in place, since the ISO certificate alone does not establish HIPAA obligations.
Tested incident response
An auditor will ask for an incident response plan and for proof that it has been exercised, not only written. Tabletop exercises or live tests should include a ransomware scenario affecting clinical systems, with recorded decisions, timings and follow-up actions. Confirm that the plan names who decides on downtime procedures and who contacts regulators and affected patients, and that lessons learned updated the plan.
Internal audit results
Clause 9.2 requires internal audits of the ISMS at planned intervals, and the certification body will review the most recent cycle before the main audit. Results should show which areas were sampled, what nonconformities were found, and whether corrective actions were closed with evidence. Ask the certification body early whether it expects to see a specific internal audit report format.
What ISO 27001 for a health organization costs and who is paid
This table separates the cost components of an ISO 27001 program for a healthcare provider or health tech vendor, showing who is paid, whether each cost is one-time or recurring, and what pushes it up. No supplied source gives a price, so request written quotes and a fixed scope from each party before comparing options.
| Cost component | Who is paid | One-time or recurring, and what drives it up |
|---|---|---|
| Certification body audit fees | The accredited certification body that issues the certificate | Stage 1 and Stage 2 audits are one-time for the initial certificate. Audit effort rises with the number of sites, systems in scope, and the health data flows the auditor must sample. Ask for the audit day count in writing. |
| Implementation partner work on scope and evidence | An outside implementation partner, if one is engaged | Mostly one-time, with some follow-on work at surveillance. Costs rise with a broad scope covering EHR, medical device software and clinical networks, and with gaps in existing evidence. Ask for a fixed scope and named deliverables. |
| Internal staff time | Your own employees, including clinical informatics, security, HR and facilities | Largely one-time during build, then recurring for reviews and access evidence. Drivers include the number of clinical applications, the state of asset records and how many staff must attend training and reviews. |
| Clinical system and tooling changes | Your EHR or medical device vendors, your integration engineers, and any tooling vendor | Often one-time for configuration, with recurring license and support fees. Changes to logging, access control or backups in clinical systems may require vendor involvement and change control. Confirm with each vendor what they will support in writing. |
| Surveillance and recertification audits | The certification body that holds the accredited certificate | Recurring. Surveillance audits occur during the three-year cycle, with a recertification audit at the end. Costs rise with scope changes, new sites or new clinical systems added between audits. |
Who owns the controls, who prepares evidence and who certifies
Your organization owns the information security management system (ISMS) and every decision inside it. That includes the scope, the risk assessment, the risk treatment choices, the Statement of Applicability and the accountability for controls that protect electronic health records, medical device software and clinical workflows. Clinical safety officers, privacy officers and the security team must agree on which care settings, including remote or virtual care, fall inside the scope. Your organization also keeps the HIPAA duties that apply to it as a covered entity or business associate, because an ISO 27001 certificate does not replace the Security Rule.
- Scope and risk decisions: Leadership approves the ISMS scope, the risk criteria and which risks are accepted, reduced or transferred.
- Statement of Applicability: Your team justifies each Annex A control as applied or excluded, with reasons tied to the risk assessment.
- Clinical and safety input: Clinical leaders decide how controls affect care delivery, downtime procedures and medical device maintenance.
- HIPAA obligations: Privacy and compliance staff map Security Rule duties that ISO 27001 does not cover, such as documentation and breach handling.
- Operation and records: Your staff run access reviews, incident handling and training, and keep the records that show those activities happened.
Before engaging anyone, confirm internally who signs the Statement of Applicability and who answers auditor questions on clinical systems.
An implementation partner such as DeployOpen prepares systems, configurations and evidence inside your environment. Work typically covers deploying self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, configuring logging, access control and backups, and documenting how each control is operated. The partner can also test technical controls and prepare the evidence packs an auditor will request. The partner does not decide your risk appetite, does not sign the Statement of Applicability on your behalf and does not issue audit reports, attestations or certificates.
- System preparation: Hardening, configuration and integration of the platforms that hold or process patient-related data.
- Evidence preparation: Exports, configuration baselines, access reviews and change records organized by control.
- Testing support: Security testing of applications and APIs that front clinical data, reported back to your team for remediation.
- Documentation: Runbooks and procedures that your staff can run after handover.
- Fixed scope: Scope, deliverables and timelines are agreed in writing before work starts, and ongoing support is available as a retainer.
Ask any partner to state in writing which tasks it performs and which remain with your staff, and whether it has any role in the certification body's work.
Only an independent certification body issues an ISO 27001 certificate. Accredited ISMS certification bodies operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. The auditor examines your documented ISMS, samples evidence and interviews staff, then reports nonconformities. A certificate runs on a three-year cycle with at least one audit in every calendar year, so your organization will face surveillance audits as well as the initial certification audit.
- Independence: The certification body must not have designed or operated the controls it audits. Check this before hiring any consultant or implementer.
- Accreditation: Confirm the body is accredited for ISO/IEC 27001 and that its certificates appear in the IAF CertSearch database.
- Audit findings: Nonconformities are raised by the auditor, and your organization decides how to correct them.
- Cycle obligations: Plan for surveillance audits each year within the three-year cycle.
- Scope of certificate: The certificate states the scope your organization defined, so unclear scoping of clinical systems carries through to the certificate.
Before signing, ask the certification body how it handles healthcare scope and whether it has auditors familiar with clinical systems and medical device software.
How to choose a certification body and an implementation partner
Certification bodies issue the ISO 27001 certificate, and implementation partners prepare your systems and evidence. Keep these two roles separate, confirm each party's standing, and settle how ISO 27799 and HIPAA evidence will be handled before any contract is signed.
Confirm the certification body's accreditation
Only an accredited certification body can issue a valid ISO 27001 certificate. Search the certificate holder or the body in the IAF CertSearch database, which ISO still points to for checking accredited certificates. Global ACI has assumed the IAF and ILAC roles since 1 January 2026, so ask the body for its accreditation number and scope and confirm both yourself rather than relying on a logo in a proposal. Check that ISO/IEC 27001 is in the accredited scope.
Keep the implementer independent of the auditor
The partner that designs your ISMS, writes policies and runs the internal audit should not be the body that certifies it. Ask the certification body whether it has any consultancy, design or tooling relationship with the firm you are considering, and ask the partner how it avoids reviewing its own work. Written separation protects the certificate's credibility when a customer or regulator asks how it was obtained.
Ask for health sector experience
Healthcare systems bring clinical safety, EHR integration, medical device software and third-party hosting into scope. Ask the partner which EHR, device or patient-facing systems it has scoped before, how it handled clinical and administrative systems in the same ISMS, and how it treated remote or virtual care. Request examples described anonymously, and ask how those examples were reviewed. Treat a general IT background without health context as a gap to close before work starts.
Ask how ISO 27799 is treated
ISO 27799:2025 provides health-specific implementation guidance on top of ISO/IEC 27002:2022. Ask whether the proposal maps the health controls to your Statement of Applicability, or whether it treats them as optional reference material. The certification body will assess against your ISMS and its stated controls, so confirm how the partner will document any health-specific control you adopt or justify excluding. Ask for the mapping in writing.
Agree how HIPAA evidence is handled
An ISO 27001 certificate does not establish HIPAA compliance. Ask the partner how it will collect Security Rule evidence such as risk analysis records, workforce access reviews and audit log retention, and where that evidence will sit. Confirm that the contract assigns responsibility for keeping business associate obligations current. A US business associate remains directly liable to OCR for Security Rule failures, so the certificate cannot stand in for that evidence.
Do not confuse HITRUST assessors with ISO auditors
HITRUST assessments are run by HITRUST external assessors or readiness licensees, a separate route from ISO 27001 certification. Your customers may ask for one, the other, or both, and each produces a different report. Before signing, confirm which credential the proposed firm holds and which body issues the output you need. Check HITRUST's assessor directory directly, and do not accept a HITRUST claim as evidence of ISO accreditation.
Questions health organizations ask about ISO 27001 and HIPAA
Can a hospital get ISO 27001 certified without ISO 27799?
Yes. ISO 27799:2025 is health-specific guidance built on ISO/IEC 27002:2022, not a separate certification, so the certificate is still issued against ISO/IEC 27001:2022. A hospital can certify without it, but the health controls in ISO 27799:2025 give implementation guidance that many clinical and medical device settings need. The organization should decide which health-specific guidance applies to its systems, record that decision in the Statement of Applicability, and confirm with its certification body how it will be assessed. ISO 27799:2025 covers electronic health record systems, medical devices containing software and remote or virtual care, so it is most useful when those systems sit inside the ISMS scope.
Does ISO 27001 certification satisfy HIPAA obligations?
No. ISO 27001 is a management system standard, and HIPAA's Security Rule (45 CFR Part 164 Subpart C) is a US legal requirement with its own standards and implementation specifications. Business associates must comply with the Security Rule and are directly liable to the HHS Office for Civil Rights for Security Rule failures. An ISO 27001 certificate can provide much of the evidence a HIPAA review asks for, but it does not replace a HIPAA-specific risk analysis, business associate agreements or the Security Rule mapping. Ask counsel and your compliance lead to map each Security Rule requirement to the controls and evidence you hold, and confirm which gaps remain.
Is a cloud-hosted EHR vendor a business associate?
Often yes, and the answer does not depend on whether the vendor can read the data. HHS guidance on cloud computing states that a cloud service provider creating, receiving, maintaining or transmitting ePHI for a covered entity or business associate is a business associate, even if it stores only encrypted ePHI and lacks the encryption key. A vendor hosting an EHR or patient-facing application for providers should assume business associate status and confirm it with counsel. The ISMS scope should then cover the hosting environment, the application, support access and the data flows that carry ePHI, not only the vendor's corporate network.
How long does ISO 27001 take for a healthcare organization?
The duration depends on the scope, the number of sites and systems, how mature the existing risk management is, and how much clinical and IT time the organization can release. This page does not give a timeline because no researched figure supports one for your environment. Build your own plan from the scope, then ask your certification body for its audit schedule. Once certified, the certificate runs on a three-year cycle under ISO/IEC 17021-1, with at least one surveillance or recertification audit in every calendar year, so the work after the first certificate is recurring rather than a one-time project.
What does ISO 27001 need from clinical and IT staff?
It needs time and decisions from both groups, and the division should be written down. IT and security teams usually own the technical controls, asset inventories, access management, logging and supplier arrangements. Clinical leaders and clinical engineering should confirm which systems support patient care, which medical devices carry software, how downtime procedures work and which staff need access to each system. Both groups should take part in the risk assessment, because the risk treatment decisions for patient-facing systems need clinical input. Ask your certification body and advisers to name the specific roles and meetings they expect before the engagement starts.
Can an internal team implement ISO 27001 without outside help?
Yes, many organizations do, provided someone owns the project and the team understands the standard's requirements and the Annex A controls. The work includes the clause 4 to 10 management system requirements, the risk assessment and Statement of Applicability, policies, internal audit and management review. Outside help is usually a judgment call based on capacity and experience with audit evidence. An implementation partner can prepare systems and evidence, but the organization keeps ownership of its controls and decisions, and only an independent certification body issues the certificate. DeployOpen plans and implements self-hosted open-source platforms in the client's own infrastructure and prepares evidence for assessment, under a written, fixed scope.
How do I check that a certification body is accredited?
Start by confirming the certification body holds accreditation for ISO/IEC 27001 from an accreditation body that is a recognized member of the international network. ISO still points to the IAF CertSearch database for checking accredited certificates, and since 1 January 2026 Global ACI has assumed the roles of IAF and ILAC. Ask the certification body to confirm that it applies ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF required all clients to be audited against by 31 March 2026. Check that your certificate's scope names your health systems, sites and cloud environments precisely, and ask for references to the auditor's health sector experience before you sign.
How DeployOpen prepares health systems and evidence for an ISO 27001 audit
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the controls and evidence an ISO 27001 assessment reviews come from systems the organization runs itself. We prepare systems and evidence; the organization owns its controls, and only an independent certification body issues a certificate.
How we scope
- Agree a written, fixed scope covering the EHR, medical device software or health platform, its hosting and its support staff before work starts.
- Map which systems handle patient data, which supporting services they depend on, and where care settings such as remote or virtual care touch the ISMS.
- Set out in writing which deliverables the organization keeps, such as policies, risk decisions and the Statement of Applicability approvals.
How we build
- Configure open-source identity, logging, backup and monitoring platforms in the client's own cloud accounts, data center or air-gapped network.
- Harden platforms against the Annex A technological controls the organization selects, and document each configuration as reviewable evidence.
- Run security testing of applications, APIs and infrastructure in the health scope, and track findings to closure with named owners.
How we hand over
- Deliver configuration records, access review exports, backup restore test results and change logs in a form the auditor can sample.
- Walk the organization's staff through the runbooks so they can operate and produce evidence without ongoing dependence on DeployOpen.
- Provide a readiness pack that maps each delivered artifact to the control it supports, with gaps listed for the organization to decide on.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes.
- Refresh evidence and re-test controls before the certification body's surveillance and recertification audits, based on the agreed scope.
- Ask the certification body and the organization's compliance lead to confirm which evidence formats they accept before the build begins.
