Every certificate names the thing it covers. A CSA certificate names a component; an SSA certificate names a control system as one supplier sells it. An ISASecure ACSSA certificate names something harder to point at: an industrial automation and control system as installed for one asset owner, with the people who run it, the procedures they follow and the contractors who maintain it. Nothing on a shelf, and no fence line either.
This article explains how the ACSSA documents make that object precise: who may apply, which documents draw the boundary, what is carved out, how the inside is structured, and how inspection differs from certification. The rest of the series is on the ACSSA filter of the Insights index.
Not a product, not a site, not a management system
ISASecure ACSSA-300, the inspection and certification requirements, and ACSSA-100, the scheme description, define the object as the IACS as deployed for a single, accountable asset owner: the installed hardware and software with the personnel, procedures and policies that operate it, in operation or ready to operate. For ACSSA purposes, running the IACS counts as a process, which is what lets an installed system be certified under the process route of ISO/IEC 17065 rather than as a product.
Three things it is not. It is not a product: a control system as a supplier sells it is the object of ISASecure SSA, and a single device or software package belongs to CSA. It is not a site as such: the boundary is a set of documents, not a perimeter, and ACSSA-304 treats the number and location of sites as a planning factor. And it is not an organisation-wide management system: the security program in scope is the one governing this IACS.
The evaluation reads that object against four parts of IEC 62443 (the security program, 2-1; the risk assessment, 3-2; service-provider support for delegated tasks, 2-4; the capabilities configured and used in each zone, 3-3) plus two ACSSA-defined policy-and-procedure-support items.
Who may apply: the asset owner only
The client is the asset owner: the organisational role accountable for the IACS, which includes its operator. Nobody else applies; service providers and product suppliers are sources of evidence.
That settles a frequent integrator question. The company that designed and commissioned the system is a service provider in ACSSA terms only if the asset owner expects it to carry out integration or maintenance tasks on the IACS during the 3.5 years after application, under a continuing support contract, say; then it is listed by the asset owner, evaluated against IEC 62443-2-4 for those delegated tasks, and asked for evidence. One whose work is finished, with no such contract, is not listed, though its integration outputs can still serve as evidence. It is never the applicant and does not hold the certificate.
The six documents that draw the boundary
ACSSA-300 requirement R1 (ISASecure_ACS.R1) has the asset owner define the IACS through six things, each kept under change control. In our own words:
| # | Document | What it fixes | Why it matters to the evaluation |
|---|---|---|---|
| 1 | The named asset-owner organisation | Which organisation is accountable for the IACS and is the applicant. | It is the name any public statement of certified status must carry, together with the ISASecure version applied. |
| 2 | The hardware and software asset inventory | Which components are inside the IACS. | It feeds the per-zone asset lists, shows which components, and so which technical capabilities, are there to be checked, and is one of the documents whose logged changes are reviewed at every surveillance audit. |
| 3 | The list of equipment under control | The physical process equipment the IACS controls or monitors. | It tells the evaluator what the system is there to do, read alongside the per-zone list of essential functions and the risk-assessment documents the application also supplies; its logged changes are also reviewed at surveillance. |
| 4 | The service-provider list | Which organisations perform integration or maintenance on the IACS. | Each listed provider becomes an evaluated entity under IEC 62443-2-4 for its delegated tasks, one result per provider; providers are never sampled. |
| 5 | The personnel assigned to interact with the IACS | Who operates, maintains, engineers and administers it. | These are the people interviewed at maturity level 3, covering every functional role that matters inside the sampled zones and conduits; role assignment and training must be complete for an operations-ready system. |
| 6 | The documented security program or programs | The policies and procedures evaluated against IEC 62443-2-1. | Several programs are allowed only if they divide the IACS hardware and software between them without overlap; documented-level results are recorded per part of the IACS that one set of policies governs, and the parts must together cover the whole IACS. |
The versions of these documents fix the IACS at an agreed month and year. That is what "the IACS" means on a report or certificate: the version-dated set of six documents, not a room full of cabinets.
Change control is not a formality: the general surveillance audits in years one and two review the changes logged to the asset inventory, the equipment list and the security-program documents, plus new or changed service-provider tasks and personnel, and spend a fixed effort probing for changes nobody logged. As an ISASecure certification body, we read an application against these six documents before anything else.
In operation or operations-ready
The IACS must be in operation or operations-ready. The second state has three conditions: the equipment is in place at the facility, set up and checked; the security-program policies and procedures are written and signed off; and the people who will touch the system have their roles and training. Mixed states are allowed, so an operating IACS with an operations-ready addition or upgrade counts as one IACS.
The criteria are the same either way; what differs is the evidence available. Where live operating evidence does not yet exist, the specifications accept other evidence types, a tabletop exercise or lab evidence for instance, and ACSSA-300's detailed surveillance rule (R26 a) has those requirements updated with live-operation evidence at surveillance.
The accountability rule and the cloud carve-out
ACSSA-300 requirement R2 adds a second boundary condition. The asset owner must hold full accountability for how every zone's hardware and software is managed, operated and maintained, and for every path by which traffic enters the IACS, leaves it, or crosses between its zones. Accountability, not who does the work, is the test; whatever fails it is carved out of the scope, and the documents' own example is a public cloud service.
A carve-out is not ignored. The evaluator checks that the asset owner's IEC 62443-3-2 risk assessment analysed the threats arriving through the interface to the excluded element. The ACSSA documents held defer IACS with cloud elements inside the scope to future versions of the program.
Service providers: in scope for 3.5 years
A service provider, for ACSSA, is an organisation the asset owner expects to carry out integration or maintenance tasks on the IACS's cyber or cyber-physical components during the three and a half years after application: the three years to recertification plus a six-month buffer. External providers qualify when they work under a contract or subcontract; an internal group qualifies too, at the asset owner's discretion, when it works under a documented agreement outside the asset owner's direct management.
Each provider is evaluated only for its delegated tasks on this IACS, never as a general IEC 62443-2-4 assessment; a later article covers the service-provider side in full.
Inside the boundary: systems, zones and conduits
Within the six documents, the IACS has a fixed structure: one or more systems under consideration, each typically the scope of one IEC 62443-3-2 risk assessment; a single one is permitted. Each is partitioned into zones and conduits. Conduits that contain devices are evaluated like zones; conduits without devices carry no separate results and are covered through the zones at their ends.
The target security level of each zone and device-bearing conduit is the asset owner's input, set by its own risk assessment. ACSSA uses it to decide which 62443-3-3 capabilities must be present and used in that zone; it awards or computes no security level of its own. The application describes each system under consideration, zone and conduit at this level of detail; ISASecure ACSSA-101, the planning guide for asset owners, provides a scope-description template in Annex A.
Two schemes, one method: inspection or certification
ACSSA is two conformity-assessment schemes: inspection, run by bodies accredited to ISO/IEC 17020, and certification, run by bodies accredited to ISO/IEC 17065. Both apply the same evaluation method and per-requirement criteria. They differ in three respects: the statement made (an inspection attests conformity to individual requirements, with no overall pass; a certification attests overall conformity), the time aspect (a certification is valid to the end of the 36th month, with annual surveillance in years one and two and recertification every third year) and the impartiality rigor expected of the body.
ACSSA-100 describes the two uses. An asset owner chooses inspection for an internal check of its security posture, to check the security readiness of an IACS about to enter operation, or to measure progress; the informational maturity level 1 exists only there. It chooses certification as a long-term public commitment, or because a customer, an insurer or a regulator rewards or requires it. The asset owner elects the scheme; the evaluator determines the maturity level each requirement reaches, and certification requires level 3 on every one.
How to read "the IACS" on a certificate
For a reader of an ACSSA certificate or public claim, three points follow. First, the IACS named is the version-dated set of six documents at the agreed month and year; later changes to them are what surveillance reviews, not what the original attestation covered. Second, any public statement of certified status must name the ISASecure version and the asset owner and must not mislead on scope; the certificate itself references a three-digit certification version. Third, ISCI publishes an asset owner's certificate information only at the asset owner's request, or provides it to a named third party.
For an asset owner the lesson is to write and version the six documents deliberately, because they are what the certificate attests. For an integrator still working on the IACS in the 3.5 years after application, the lesson is to expect a place on the service-provider list, a delegated-task description and an agreed list of applicable IEC 62443-2-4 requirements. The certificate, when it comes, is the asset owner's.
Frequently asked questions
Not as such. The object of an ACSSA evaluation is the industrial automation and control system as one accountable asset owner has deployed it: its hardware, software, people, procedures and policies, bounded by six documents the asset owner keeps under change control. A fence line is not one of them. The planning guidance does weigh the number and location of sites when an evaluation is planned, but what the certificate attests is the IACS those six documents describe, at the month and year their versions fix.