Ask an asset owner what an ISASecure ACSSA evaluation will do to their plant and many picture a team arriving with scanners and trying to break something. Product certification has trained that expectation, and for ACSSA it is wrong. The evaluator who assesses an installed industrial automation and control system (IACS) never tests it and never logs into it. Evidence is gathered in three ways instead, and graded for what it shows about how the system is run.
Three ways evidence is gathered
ACSSA-101, ISCI's planning guide for asset owners, describes three evidence-gathering activities, followed by recording the findings against the ACSSA-311 workbook and the ACSSA-303 report template.
| Activity | What it reaches | Who takes part |
|---|---|---|
| Documents and artifacts | Written policies and procedures; technical records such as configuration exports; the IEC 62443-3-2 risk assessment; architecture drawings that show zones and conduits; contracts and agreements with service providers; records left behind when a procedure ran, from the owner and from its providers; the security documentation product suppliers publish for what they sold | Asset owner, service providers, product suppliers |
| Interviews | Whether the people who administer, maintain and operate the IACS know the procedures and follow them, and whether provider and supplier staff do the same for the tasks delegated to them | Asset-owner administrators, maintenance and operations staff; service-provider and product-supplier representatives |
| Inspection of systems and networks | How zones are physically separated; how the network is segmented and set up; the settings on the systems themselves; any compensating measure standing in for a capability that is absent | Asset-owner staff operating the systems while the evaluator watches |
"Inspection" in that last row has its everyday meaning; ACSSA also uses the word for one of its two schemes, the inspection scheme under ISO/IEC 17020 that shares this evaluation method with the certification scheme under ISO/IEC 17065.
Documented versus practised
The three activities pull different weight at the two maturity levels. Level 2 asks whether documented, approved policies and procedures exist for a requirement, so it is mostly a document review. Level 3 asks whether they are followed for this IACS, and that is where interviews, observation and configuration inspection earn their place. Execution records, the evidence that a policy or procedure was actually carried out, bridge the two: a completed access review, a patch log, an incident ticket worked to closure. They are documents, but documents that exist only because the procedure ran.
Certification requires level 3 on every requirement, and the evaluator, not the applicant, decides which level the evidence supports. A well-organised binder gets you to level 2. The people, the records and the configurations get you to level 3.
No testing, no device access
ACSSA-304, ISCI's planning-and-execution guide, is unambiguous: the evaluator does no testing of its own and does not access devices. Where a method needs something demonstrated, the evaluator accompanies a member of your staff while they carry out the task. Where a configuration needs examining, the evaluator asks you for it or watches your staff open it on screen. The system is inspected, not operated.
The contrast with the ISASecure product schemes is deliberate: a CSA or SSA evaluation includes tests the laboratory performs itself, among them a scan for known vulnerabilities, and what the lab tests itself covers that side. A certified product installed in one of your zones is useful evidence that a capability exists there, but the ACSSA evaluator still checks that it is configured and in use the way your policies say. As an ISASecure certification body, Perseus works under the same rule: our evaluators watch your people operate the system and never operate it themselves.
What the workbook's D, O and T letters mean
The ACSSA-311 workbook attaches an artifact type to many of its 422 evaluation methods: D for documentation, O for observation, T for test, alone or in combination.
The workbook's legend: D documentation, O observation, T test. 80 methods involve observation and 40 carry a test letter — read against ACSSA-304's rule that the evaluator performs no testing: the asset owner or its provider exercises the control while the evaluator observes. Source: ISASecure ACSSA-311 v1.3.
Documentation alone accounts for 177 methods and another 160 carry no letter, so for most methods the workbook records neither observation nor test. The observation and test letters gather in the technical part of the evaluation:
| Part | D only | D + O | D + T | D + O + T | O only | O + T | No letter | Total methods |
|---|---|---|---|---|---|---|---|---|
| IEC 62443-2-1 (with the 2 support items) | 64 | 22 | 4 | 5 | 0 | 0 | 58 | 153 |
| IEC 62443-2-4 | 79 | 1 | 1 | 0 | 0 | 0 | 42 | 123 |
| IEC 62443-3-2 | 33 | 0 | 0 | 0 | 0 | 0 | 0 | 33 |
| IEC 62443-3-3 | 1 | 0 | 0 | 0 | 22 | 30 | 60 | 113 |
Every risk-assessment method is a document review, and service-provider methods carry the documentation letter or none, with two exceptions. The IEC 62443-3-3 capability methods, evaluated at maturity level 3 only, supply all 22 observation-only and all 30 observation-plus-test methods, hence 30 of the 40 that carry a test letter.
How can the workbook mark 40 methods with a test letter when the evaluator performs no testing? The letter is the workbook's own legend for the kind of evidence a method draws on, read against ACSSA-304's rule. Your staff or your service provider exercise the control while the evaluator observes and records: a failover is triggered, for instance, or a backup is restored. The evaluator witnesses a test; it never runs one. Consistent with that, T never appears alone in the workbook.
Three phases can be remote; one cannot
ACSSA-304 organises an evaluation into four phases: the risk-assessment evaluation, the maturity-level-2 evaluation, the maturity-level-3 evaluation and preparing the report. Phases 1, 2 and 4 may be conducted remotely. Phase 3 may not: it is where configuration and physical practice are checked, and neither can be judged from a conference call, so ACSSA-304 places it on site, including at the premises of service providers where delegated work is done. A small single-site asset owner may see every phase happen there.
Interviews are mandatory and documented. For measures people carry out, ACSSA-300 expects the evaluator to talk to someone from each functional role involved within the sampled scope; the role names it offers as examples are operator, maintenance, engineering, IT/OT administrator and security lead. The rule counts roles, not zones, and the evaluator may accept a written questionnaire in place of a conversation.
When live evidence does not exist yet
ACSSA accepts an IACS that is operations-ready: installed and configured, its testing finished, its policies approved, its roles filled and its staff trained, but not yet running. It is evaluated to the same criteria as an operating system, though some level-3 evidence cannot exist yet. ACSSA-100 notes that the specifications allow several kinds of evidence in that situation, and ACSSA-300's surveillance rule R26 a) names tabletop exercises and laboratory testing as examples. That rule requires the security-program requirements passed on such evidence to be revisited at surveillance, with live-operation evidence where that evidence is by then expected to exist. The evaluator's role is unchanged: it observes and performs no test of its own.
What you submit with the application
ACSSA-300 lists what the asset owner provides about the IACS (its rule R6) and about each service provider (R7).
For the IACS and each system under consideration
- The list of systems under consideration and, for each, its asset inventory, equipment under control, assigned personnel, service providers and governing security-program documents.
- The IEC 62443-3-2 risk-assessment documentation for each system under consideration.
- Zone and conduit drawings; an asset inventory per zone; zone-level risk-assessment documents where the risk assessment called for them; the essential functions each zone hosts; the target security level of every zone and device-bearing conduit; and whether each is in operation or operations-ready.
- System documentation sufficient to support the workbook's activities, plus the artifacts and access needed for observation and interviews.
For each service provider
- The legal entity, a short title for its task and a one-sentence description of what it does for this IACS.
- The contract portions that describe those tasks. Drafts under change control are acceptable, and an agreed task description substitutes where no contract exists.
- The list of IEC 62443-2-4 requirements that apply to the provider, agreed between evaluator and asset owner and always including the SP.01 requirements that ACSSA-300 Table 4 identifies as applying to most or all providers.
- Any relevant IEC 62443-2-4 certificate at maturity level 3 or 4. One issued by a body accredited by an IAF MRA signatory can carry the corresponding requirement at level 2; level 3 still needs evidence of execution for this IACS.
ACSSA-300 also sets a sourcing order for system documentation. For an off-the-shelf system it comes from the product supplier. For an integrated system it comes first from the integrator, then from the integrator together with the component suppliers, and only then is it developed by the asset owner, with verification. Dealing with suppliers is the asset owner's responsibility, with the evaluator's support. A legacy system whose documentation cannot be obtained is not automatically failed: the gap can be handled through a documented risk justification, one of the three special-circumstance results that pass only with documentation approved by the asset owner and every affected stakeholder.
Seven areas to have in order
ACSSA-101 §6 names seven areas an asset owner needs in shape before an evaluation can succeed.
| Area | What the evaluator will do with it |
|---|---|
| A security program | The IEC 62443-2-1 policies and procedures, and the records of carrying them out; the spine of every composite verdict |
| Security risk assessments | The IEC 62443-3-2 output that sets each zone's target level and so decides which capability requirements are checked where |
| Zone and conduit partitioning | The architecture the level-3 sample is drawn from and the boundary every zone-level result is recorded against |
| An IACS asset inventory | The population of hardware and software the evaluation is about; one of the six documents that define the scope |
| Service-provider agreements and responsibilities | The basis for deciding which IEC 62443-2-4 requirements apply to which provider |
| Product suppliers, and the security documentation for the system they supplied | The source of configuration and capability evidence for the IEC 62443-3-3 methods |
| Incident response and recovery | Procedures, and records of drills or real events, for requirements that can only be shown practised by having been practised |
Its Annex A adds a scope-description template worth completing before the first conversation with a certification body.
The short version
Bring the documents that say what you do, the records that show you did it, the people who did it, and the configurations that show how the system is set up. Nobody is coming to attack your plant. The certificate depends on how well the evidence from those three activities holds together at maturity level 3, requirement by requirement, and the rest of this series covers how those requirements are counted, sampled and graded.
Frequently asked questions
No. ACSSA-304 rules out testing by the evaluator and access to devices. Where a method needs a control demonstrated, your staff or your service provider perform the task while the evaluator observes. Testing by the certifier belongs to the ISASecure product schemes, CSA and SSA, not to ACSSA.