Yes. ISO 27001 explicitly allows you to accept information security risks instead of treating them, but only in a controlled, documented way that aligns with your business, contractual, and regulatory obligations.
What ISO 27001 actually expects
Risk acceptance is one of the possible outcomes of the risk treatment process. To be consistent with ISO 27001, you need to:
- Use a defined and repeatable risk assessment method (including likelihood and impact criteria).
- Determine your organization-wide risk acceptance criteria and have them approved by management.
- Evaluate each risk against those criteria and applicable obligations (regulatory, contractual, internal policies).
- Choose a treatment option: reduce, avoid, share/transfer, or accept.
- Document the decision and rationale if a risk is accepted.
ISO 27001 does not prohibit accepting risks; it requires that you manage the process and be able to demonstrate how and why a risk was accepted.
When risk acceptance is usually not appropriate
Even if ISO 27001 allows the mechanism, you cannot simply “accept” a risk that conflicts with hard external requirements. In regulated manufacturing environments, risk acceptance is often constrained by:
- Regulation and law: Export controls, privacy laws, sector-specific cybersecurity rules, and safety-related regulations may require specific controls. You cannot accept non-compliance as a risk decision.
- Contractual obligations: OEM or government contracts often mandate named standards or controls (for example, specific encryption, access control models, or logging). Risk acceptance cannot override these.
- Internal policies: Corporate information security and safety policies may define non-negotiables (for example, multi-factor authentication for remote access to OT networks).
- Safety and product integrity: For systems tied to product quality, patient safety, or airworthiness, “accepting” risks that could compromise traceability, quality records, or safety functions is usually not tolerable.
In these cases, your options are typically to remediate, redesign, or in rare cases restrict or retire the affected process or system, not to accept the risk.
What a compliant risk acceptance decision looks like
For risks that can legitimately be accepted, you should be able to show the following elements:
- Clear description of the risk: Asset, threat, vulnerability, impact on confidentiality, integrity, and availability, and any downstream impact on quality, safety, or regulatory records.
- Measured risk level: Assessed likelihood and impact using your defined method, including a comparison to your acceptance criteria.
- Context and constraints: Why further treatment is not proportionate or feasible (for example, legacy equipment that cannot be patched without requalification or unacceptable downtime).
- Compensating controls: Any partial mitigations (network segmentation, procedural controls, enhanced monitoring, restricted usage windows).
- Risk owner: A named owner with appropriate authority (typically at business or plant leadership level, not just IT).
- Formal approval: Documented management sign-off, often through the risk treatment plan and Statement of Applicability.
- Review cadence: A defined date or trigger for re-evaluating the risk (for example, next ISMS review cycle, system upgrade, contract renewal).
This level of documentation is important in audits: you are not showing “no risk,” you are showing controlled, reasoned acceptance within defined boundaries.
Brownfield and legacy OT realities
In mixed OT/IT environments, many plants face risks driven by legacy equipment and long asset lifecycles. Common examples include:
- Legacy control systems that cannot be patched or upgraded without revalidation or recertification.
- Production-critical servers running unsupported operating systems, tied to validated MES/QMS integrations.
- Vendor-locked equipment where secure configuration options are limited.
In these situations, ISO 27001 does not require you to replace everything immediately. It expects you to:
- Identify and assess the risks realistically, considering impact on production, quality, and safety.
- Apply feasible compensating controls (for example, segmentation, strict access control, tight change control, enhanced logging, and procedures).
- Make a documented decision if the residual risk above those controls remains and must be accepted temporarily.
- Link risk acceptance to a roadmap (planned upgrades, vendor replacement, or architectural changes) rather than accepting risk indefinitely by default.
Full replacement of critical systems just to close a single information security gap is often impractical in heavily regulated manufacturing due to requalification burden, downtime risk, and integration complexity. ISO 27001-compatible risk acceptance can bridge that gap, provided the decision is explicit, justified, and periodically revisited.
Operational safeguards around accepted risks
If you accept a risk, you still need guardrails to keep that decision under control:
- Change control: Any change to the affected system, network, or process should trigger a recheck of the accepted risk and its assumptions.
- Monitoring and incident response: Increased monitoring of the affected assets, with clear procedures if indicators of compromise or failures appear.
- Traceability: Link the accepted risk to impacted processes, equipment, and records so that quality and operations leaders understand potential effects.
- Cross-functional visibility: Involve operations, engineering, quality, and IT in reviews; accepted security risks can have downstream quality and compliance impact.
These practices do not make the risk go away; they reduce surprise and support defendable decisions in audits and internal reviews.
ISO 27001 and audit considerations
Accepting risks does not prevent you from being certified to ISO 27001, but it can create audit findings if managed poorly. Typical audit issues include:
- Risk acceptance criteria not clearly defined or not approved at the right level.
- Risks “implicitly” accepted because no treatment decision was recorded.
- Accepted risks that contradict legal, regulatory, or contractual requirements.
- Risk decisions made only in IT, with no involvement from process or quality owners.
- Accepted risks that are never revisited, even as the environment changes.
To avoid this, ensure that risk acceptance follows your ISMS procedures, is clearly traceable, and is visible in management reviews.
