Do we need to implement all 93 Annex A controls?

No, you do not have to implement all 93 Annex A controls exactly as written. Under ISO/IEC 27001, Annex A is a catalogue of possible controls that you select from based on risk. What is required is a structured, justified decision on which controls are applicable, how they are implemented, and why any are excluded.

What the standard actually requires

ISO/IEC 27001 requires you to:

• Define the scope of your ISMS, including which sites, systems, and processes are in scope.
• Perform a formal risk assessment covering information assets, threats, vulnerabilities, and impacts.
• Select controls that are appropriate and proportionate to the identified risks.
• Compare your chosen controls to Annex A and decide for each Annex A control whether it is:
• Implemented as described, or
• Implemented in an equivalent or compensating way, or
• Not applicable, with a clear justification.
• Document all of this in a Statement of Applicability (SoA) and keep it under change control.

The SoA is the key evidence. It must show that you considered all Annex A controls and can explain your choices. Auditors typically focus on your reasoning and consistency, not on a one-to-one implementation of all controls.

When you might effectively adopt most or all controls

In many industrial and regulated environments, the outcome of a risk assessment is that a large share of the Annex A controls are relevant, for example:

• Plants with safety-critical or export-controlled systems.
• Facilities handling customer or defense data under contract clauses that reference ISO/IEC 27001 or related frameworks.
• Complex vendor ecosystems with external connectivity into OT networks.

In such cases, you may end up implementing most Annex A controls in some form, but this still comes from risk and feasibility analysis rather than a blanket rule. Some controls will be applied differently between enterprise IT and OT environments.

Brownfield and OT realities

In existing plants with legacy MES, PLCs, SCADA, and long-lived equipment, certain Annex A controls are difficult or disruptive to implement as written. Typical examples:

• Technical constraints: Legacy controllers may not support modern authentication, patching cadence, or encryption without hardware replacement.
• Downtime risk: Applying controls that require firmware changes, OS upgrades, or network re-segmentation may create unacceptably high outage or re-qualification risk.
• Vendor lock-in: Some controls depend on vendor capabilities or release cycles you do not control.
• Validation burden: In GMP-like or aerospace environments, each security-relevant change to validated systems may trigger revalidation, test execution, and documentation updates.

In these cases, you typically rely on a combination of:

• Compensating controls (for example, physical segregation, network zoning, monitoring).
• Procedural controls (for example, strict change management and manual checks).
• Explicit risk acceptance, with leadership sign-off and review cycles.

The important part is that your SoA and risk register make these constraints and decisions traceable and defensible.

How to decide which Annex A controls to implement

A practical, risk-based approach usually includes:

1. Map assets and processes
   Identify critical assets: production equipment, process data, recipes, NC programs, quality records, export-controlled data, and safety-related systems.
2. Run a structured risk assessment
   Use a consistent method to rate impact and likelihood, and consider OT-specific scenarios such as loss of availability, integrity of setpoints, and cross-contamination between OT and corporate networks.
3. Prioritize high-impact risks
   Focus first on controls that reduce risks of safety incidents, production outages, product quality escapes, and regulatory breaches.
4. Assess feasibility in your current environment
   Identify where a control can be implemented directly, where it needs tailoring, and where a compensating control is more realistic due to legacy constraints.
5. Document decisions in the Statement of Applicability
   For each Annex A control:
• Mark it as applicable/not applicable.
• Describe how it is implemented or the compensating approach.
• Record justifications, dependencies, and any residual risk.
6. Integrate with change control and validation
   Ensure any control changes that touch validated systems, safety functions, or regulated data flows go through your change control process and required testing/verification.

Why “implement everything” is often impractical

A mandatory, one-size-fits-all rollout of all 93 controls typically fails in regulated manufacturing for several reasons:

• Qualification and validation burden: Modifying OT, MES, or QMS functionality to meet specific security controls can trigger protocol requalification, software validation, and documentation changes.
• Downtime and cost: Plant shutdowns to re-architect networks, replatform legacy systems, or replace controls hardware can be prohibitive.
• Integration complexity: Controls that look simple on paper (for example, centralized logging, unified access management) become complex in multi-vendor, multi-generation environments.
• Traceability and configuration management: A rapid, broad rollout can outpace your ability to maintain accurate inventories, baselines, and configuration records, which undermines both cybersecurity and audit readiness.

These are not reasons to avoid controls entirely; they are reasons to prioritize, stage implementation, and use compensating measures while you phase in deeper changes.

Coexistence with existing IT, OT, and quality systems

Annex A controls are typically realized through combinations of:

• Existing IT security tools (identity, logging, endpoint protection, backup).
• OT network segmentation, firewalls, and secure remote access solutions.
• MES, ERP, and QMS configuration and procedures (for example, access control, audit trails, document control).
• Plant floor procedures and training (for example, removable media handling, vendor access rules).

In most brownfield environments, you are layering Annex A controls onto what already exists rather than replacing core systems. Replacement strategies that ignore the validation, integration, and downtime implications tend to stall or be scaled back once they reach complex, high-value assets.

What auditors usually look for

While individual auditor expectations vary, they will typically check that:

• Your risk assessment is methodical, repeatable, and aligned with your scope.
• Your Statement of Applicability covers all Annex A controls and is internally consistent.
• Controls you claim to have implemented actually exist and are operating effectively, with evidence.
• Exclusions and compensating controls are justified in the context of your risks and constraints.
• Changes to controls follow defined change control and are reflected in current documentation.

They do not require that every Annex A control be implemented identically across all sites or systems, as long as your risk-based rationale is documented and applied consistently.

In summary, you are required to consider all 93 Annex A controls, document applicability, and implement appropriate measures based on risk and feasibility. You are not required to implement every control exactly as written, especially where brownfield OT, validation, and integration constraints make this impractical, provided your justifications are clear, evidence-based, and maintained under change control.