ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A cybersecurity requirements specification (CRS) is the document that turns an IEC 62443-3-2 risk assessment into requirements an integrator can design to, a supplier can price, and a test team can verify. Without one, the zones, conduits and target security levels you agreed in workshops stay in a spreadsheet and never reach the contract.
In IEC 62443-3-2:2020, the CRS is requirement ZCR 6.1, part of the step that documents security requirements, assumptions and constraints. It sits between the detailed risk assessment (ZCR 5) and asset owner approval (ZCR 7). Note that the standard writes “cyber security” as two words; we use the one-word industry spelling.
Think of the cybersecurity requirements specification as the security design basis for one system under consideration (SUC). It records the zones and conduits, the target security level (SL-T) for each, the applicable security requirements, and the assumptions and constraints the design relies on.
IEC 62443-3-2 builds toward the CRS in seven steps:
Steps 1 to 5 generate the inputs; the CRS is where they land. New to the assessment? Start with our IEC 62443 risk assessment guide, and see how the IEC 62443 parts fit together. The standard is listed on the IEC webstore page for IEC 62443-3-2:2020 (US edition: ANSI/ISA-62443-3-2-2020).
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
The standard addresses asset owners, system integrators, product suppliers, service providers and compliance authorities. The CRS is often the one document all of them read, so precision matters more than length.
ZCR 6 has nine sub-requirements. ZCR 6.1 is the CRS itself; the other eight describe what it must capture. You can fold all nine into one document or keep the CRS as a master file referencing controlled attachments.
Teams skip the assumption items most often. They matter because an SL-T chosen for a locked, staffed control room is wrong for an unmanned remote site. Written assumptions show the next assessor when they stop being true.
The standard tells you what to document, not how to lay it out. Below is the structure we recommend as an IEC 62443 CRS template, with traceability from each requirement back to the risk assessment and forward to a test.
| Section | What it contains | Source input |
|---|---|---|
| 1. Document control | Scope, version, owner, approvers, change history | Document management procedure |
| 2. SUC description | Purpose, functions, boundary, external interfaces | ZCR 1 output, system architecture |
| 3. Zone and conduit drawings | Logical and network architecture with zones, conduits and entry points | ZCR 3 output |
| 4. Zone and conduit register | One record per zone and conduit, including SL-T | ZCR 3 and ZCR 5 outputs |
| 5. Threat environment | Threat sources, vectors and assumed attacker capability | ZCR 5 threat identification, threat intelligence |
| 6. Risk summary | Unmitigated and residual risk per zone, tolerable risk criteria | ZCR 2, 4 and 5 results, corporate risk matrix |
| 7. System security requirements | Requirements per zone and conduit, mapped to IEC 62443-3-3 SRs at the SL-T | IEC 62443-3-3, ZCR 5 countermeasures |
| 8. Component requirements | Capabilities required of devices and software in each zone | IEC 62443-4-2 CRs, supplier data |
| 9. Integrator and service requirements | Practices required of the integrator and maintenance providers | IEC 62443-2-4, contract terms |
| 10. Assumptions and constraints | Operating environment, legacy limits, compensating countermeasures | ZCR 6.5, operations and maintenance input |
| 11. Policies and regulations | Applicable corporate policies and regulatory obligations | ZCR 6.7 and 6.9, legal and compliance |
| 12. Verification matrix | Test method and acceptance criterion per requirement (FAT, SAT, inspection) | Project test strategy |
| 13. Approval | Asset owner sign-off, accepted residual risks, conditions | ZCR 7 |
Section 7 is the heart of the document. IEC 62443-3-3 provides 51 system requirements grouped under seven foundational requirements, from identification and authentication control to resource availability. Selecting the ones that apply at each zone’s SL-T gives you a defensible baseline. Our guide to IEC 62443 security levels explains how SL-T, SL-C and SL-A relate.
Each requirement should be atomic and testable, with a unique ID, a link to the risk scenario or system requirement that justifies it, and an owner. “The system shall be protected against remote attacks” cannot be verified. Compare:
The asset owner owns the CRS. ZCR 7 closes the process with asset owner approval, which turns a consultant’s draft into the basis of design. Consultants and integrators can author it but cannot accept risk on the owner’s behalf.
A practical review and approval chain:
Record each accepted residual risk and its conditions in the approval section. Require re-approval when the SUC, threat environment or tolerable risk criteria change.
A CRS earns its keep after approval, linking the risk assessment to what is bought, built, tested and changed.
Attach the CRS, or a supplier-facing extract, to the request for proposal. Ask bidders to respond per requirement: compliant, compliant with a compensating countermeasure, or non-compliant. This forces the security conversation before the price is fixed. Strip sensitive detail such as IP addressing from the tender version.
The integrator converts the CRS into firewall rule sets, account structures, hardening baselines and logging architecture. An integrator working to IEC 62443-2-4 should show how each requirement is met. Where a component’s SL-C is below the zone’s SL-T, the design documents the compensating countermeasure and the owner accepts it.
The verification matrix becomes the security test plan. FAT proves what can be shown at the vendor’s facility: hardening, accounts, rule sets, backup and restore. SAT proves what only appears on site, such as real conduits and remote access paths. Failed security items go on the punch list like any other defect.
After handover, the cybersecurity requirements specification becomes the reference for change control. Check any change that adds a connection, moves an asset between zones or opens a remote access path against the CRS. If it breaks an assumption or requirement, reassess the zone and update the approval.
These three specifications look similar on a document register but answer different questions. The CRS should cross-reference the other two, not duplicate them.
| Aspect | Functional specification | Safety requirements specification (SRS) | Cybersecurity requirements specification (CRS) |
|---|---|---|---|
| Question it answers | What should the control system do? | What must each safety function do? | What must the system resist, and to what level? |
| Driven by | Process design and operating philosophy | Process hazard and risk analysis | Cyber security risk assessment (IEC 62443-3-2) |
| Typical content | Control narratives, I/O, alarms, interlocks, HMI | Safety functions, SIL, safe states, trip points, response times | Zones, conduits, SL-T, security requirements, assumptions and constraints |
| Reference standard | Project or company standards | IEC 61511 (process sector) | IEC 62443-3-2, with 3-3, 4-2 and 2-4 |
| Verified by | Functional FAT and SAT | SIS validation and proof testing | Security FAT and SAT, periodic reassessment |
The overlap is the safety instrumented system (SIS). IEC 61511-1 calls for a security risk assessment of the SIS, and ZCR 3.3 separates safety-related assets into their own zones. Cross-reference the CRS and SRS so a change to one prompts review of the other.
The issues we flag most often in CRS reviews:
If you would rather not start from a blank page, the IEC 62443 Toolkit includes a Cybersecurity Requirements Specification template in its risk assessment section, plus zones and conduits documents and an SL-T/SL-C/SL-A gap workbook, among 117 editable templates (82 Word, 35 Excel) for asset owners and service providers. It supplies the documented layer; your team still runs the assessment, makes the decisions and keeps the records.
IEC 62443 is voluntary unless a regulator, customer or contract requires it. If you claim conformance with IEC 62443-3-2, though, ZCR 6.1 requires a CRS. An assessor reviewing 3-2, for example under the ISASecure ACSSA scheme for operating IACS, would typically expect to see one.
Either can draft it, and on capital projects a consultant or integrator often does. Approval stays with the asset owner under ZCR 7, because only the owner can accept residual risk. The integrator reviews for buildability and declares deviations.
A CRS is written per system under consideration. A large site may have several SUCs, such as a distributed control system and a utilities system, each with its own CRS. Shared elements like the site DMZ can sit in a common annex.
Yes. In our experience the ZCR process works for brownfield systems too; the assumptions and constraints section simply carries more weight, because legacy assets often cannot meet the SL-T directly. Document the gap, the compensating countermeasures and a target date for closing it.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026