OT and ICS security assessment

What an OT and ICS security assessment protects when uptime is non-negotiable

An OT and ICS security assessment gives a plant, utility or building operator defensible evidence of how its control environment is built and defended, and it does so without putting production at risk. If a customer, insurer, regulator or board has asked for OT security evidence, the assessment answers that request by reviewing architecture, zones, remote access and configuration, and by testing only where the test cannot disturb the process. The work is planned around safety and uptime from the first scoping call, because a test that stops a controller or a safety function is a failed test regardless of what it finds. The reasoning comes from NIST SP 800-82 Rev. 3, published in September 2023, which covers industrial control systems, building automation, transportation systems and physical access control systems. The guide recommends security countermeasures that keep performance, reliability and safety requirements intact. An assessment therefore has to respect those constraints in its own method. The risks it is designed to surface include unauthorized control changes to setpoints, logic or firmware, loss of visibility into what is connected and what it is doing, unsafe remote access paths for vendors and integrators, and flat networks where a compromise in the business IT zone can reach control zones directly.

Operators usually commission this work, but the request often comes from outside the operations team. Plant managers, control system engineers, the CISO, the risk function and an insurer's underwriter may each need a different part of the answer. Before signing a scope, the buyer should confirm which zones and conduits are in scope, which safety-instrumented or time-critical functions must stay untouched, who on site can stop any activity, and whether testing will occur during a production window or a planned shutdown. Ask the provider to state in writing which activities are passive, which are active, and which are excluded for safety reasons. That written boundary is what lets the operator approve the work with confidence.

What can be in scope for an OT and ICS security assessment

An OT assessment is shaped by the sites, zones and assets the client chooses to include, and by how much activity each one can safely tolerate. The cards below describe the components we most often see scoped, what you decide for each, and the controls that apply before any step touches a live process.

Architecture and zone review

We review how the control environment is divided into zones and conduits, where the boundaries to corporate IT sit, and whether the segmentation matches the security levels your own risk assessment set. The review uses the zone model in ISA-62443-3-2 and the system requirements in ISA-62443-3-3 as the reference points. You decide which sites and zones are covered. Before any active step, the rules of engagement, safety contacts and stop conditions are agreed in writing with your operations team.

Asset inventory and passive discovery

Many OT environments have no reliable list of what is connected, which firmware runs on each device, or which systems talk to each other. Passive discovery observes existing traffic on mirrored or tapped links, so it adds no polling or scanning load to controllers. You decide which network segments are monitored and for how long. Any change to monitoring points or capture settings is agreed in writing beforehand, and no active probing happens unless it has been separately approved.

Configuration and remote access review

This component checks controller and network device configuration against your hardening baseline, including default credentials, unused services, firmware versions and logging. Remote access paths such as vendor VPNs, jump hosts and remote desktop gateways are reviewed for who can reach what, how sessions are approved and recorded, and how credentials are stored. You decide which device classes and vendor access paths are in scope. Read-only review of configuration exports is preferred, and any on-device check is agreed step by step with the asset owner.

Engineering workstations and historians

Engineering workstations hold the logic and project files that change how processes run, and historians aggregate process data across sites. Both are frequent routes between corporate networks and control zones. The review covers patching, application control, removable media handling, account separation, and how data flows from the historian outward. You decide which workstations and servers are included and whether the review is on live systems or on exported images. Any step that could interrupt an engineering session is agreed in advance with the plant team.

Limited active testing

Active testing is kept narrow in OT. Typical steps are targeted checks of specific services, authentication behavior and segmentation rules, run in agreed windows against assets the asset owner has approved. Test hosts, maintenance periods and the stop conditions are fixed in the rules of engagement, and a named safety contact can halt any step immediately. Findings are mapped to the tactics and techniques in MITRE ATT&CK for ICS so you can see which adversary behaviors the environment would and would not resist.

Documentation review

Architecture diagrams, network inventories, change records, backup and recovery procedures, and incident response plans show whether the environment is managed as designed. We compare these documents with what the review observes, so gaps between paper and practice are visible. You decide which documents are supplied and who at your organization answers questions about them. The documentation review also supports the evidence a later audit or customer review will ask for, and we confirm with your assessor which artifacts they expect.

How an OT and ICS security assessment runs without stopping the plant

The sequence moves from paperwork and passive observation toward active testing only where the operator has approved it, so each finding is grounded in how the plant really runs and no step puts safety or uptime at risk.

Agree scope and rules of engagement
The assessment starts with a written scope that names the sites, zones, process areas and systems in play, along with the plant safety owner, the operations contact and the people who can stop work. Rules of engagement set what is allowed, what is off limits, how changes are approved, and how communication runs during a shift change or an incident. DeployOpen does not begin any technical step until the operator has signed off on these rules. The output is a signed scope document and a named stop authority for every area in scope.
Review architecture and zone documentation
The team reviews network diagrams, asset inventories, data flow descriptions and any existing risk assessments against the system requirements in ISA-62443-3-3, which covers security levels for industrial automation systems. The goal is to see where zones and conduits are defined, where the boundary to business networks sits, and where documentation disagrees with the plant as built. Gaps in the documents become questions for the operator to answer before any traffic is observed. The check is complete when each zone in scope has a documented boundary and a list of open questions the operator has acknowledged.
Observe traffic and discover assets passively
Passive discovery means listening to existing network traffic on monitored points, such as a span port or a mirrored feed agreed with the operator, without sending probes to controllers. Engineers compare what they see with the inventory from the previous step to find unknown devices, unexpected protocols, remote access paths and communication between zones that should not talk. Where a network sensor is already deployed, the team works from its data. The output is a reconciled asset and communications map, with each deviation recorded and assigned to the operator for confirmation.
Review controller and supporting system configuration
Engineers review configuration exported or read through the operator's own procedures for controllers, engineering workstations, historians, firewalls, remote access gateways and directory services that support the plant. They check items such as default or shared accounts, unused services, firmware versions against vendor advisories, logging, backup and patch practice, and how engineering changes are authorized. Reviews are read-only, and the operator's engineers run any export or collection step. The output is a configuration findings list tied to specific assets, with evidence references the operator can verify.
Run limited active tests in an approved window
Active testing is the last technical phase because it carries the most operational risk. Each test is written as a short procedure that names the target, the expected effect, the rollback or recovery step, and the person who can halt it. The operator approves the window, usually during a planned outage or on a non-production replica where one exists. Every active step has a safety owner from the operator's side and a stop condition, such as a controller alarm, a loss of process visibility or an operator request, that ends the step immediately. The output is a timed activity log showing what ran, when it stopped and what changed.
Map findings to ATT&CK for ICS tactics
Each finding from the earlier phases and the active window is mapped to the techniques and tactics in the MITRE ATT&CK for ICS matrix, which lists 12 tactics from Initial Access through Impact. The mapping shows which adversary objectives a weakness would support, such as gaining a foothold through remote access or affecting process control, which helps the operator prioritize. Engineers also note compensating controls that already limit a path. The output is a findings register where each item carries a severity, an affected zone, an ATT&CK for ICS mapping and a proposed remediation owner.
Deliver the report and agree remediation
The report separates executive summary, technical findings, the record of what was tested and what was deliberately excluded, and the safety notes that apply to each recommendation. Remediation items are discussed with plant engineering, because some fixes need a planned shutdown or a change control process that the operator runs. The report is complete when the operator has accepted the findings, the remediation owners and the retest scope in writing.
Retest fixed findings
Retest confirms that agreed fixes work and that they did not open new paths. It uses the same rules of engagement and the same stop conditions as the original assessment, and it only repeats active steps the operator approves again. Findings that the operator chose to accept as risk are recorded with the reasoning and an owner for review. The output is a retest letter or updated register that states which findings are closed, which remain open and why.

Which OT weakness categories the assessment checks and why they matter

This table compares the weakness categories an OT and ICS assessment typically checks, how each one shows up in industrial environments, the ATT&CK for ICS tactic family it maps to, and the operational impact if it is exploited. Use it to decide which areas deserve time in a limited, safety-conscious test plan.

Weakness category	How it appears in industrial environments	ATT&CK for ICS tactic family	Operational impact if exploited
Flat or poorly segmented networks	Business IT, historian, and control networks share broad routing or firewall rules, so a compromise in corporate IT can reach controllers and HMIs.	Lateral Movement and Initial Access	Attackers can move from office systems toward process control, disrupting production or safety functions.
Exposed or weakly authenticated remote access	Vendor support tunnels, remote desktop gateways, or VPNs reach control zones with shared accounts or no multi-factor authentication.	Initial Access	Unauthorized remote sessions can change setpoints or stop processes outside normal operator oversight.
Default or shared credentials on engineering and HMI assets	Engineering software, HMI panels, and network devices keep vendor defaults or one login shared across shifts and contractors.	Lateral Movement and Execution	Anyone with the shared login can alter logic or operator views, and changes are hard to attribute.
Unpatched or unsupported components	Legacy operating systems, controllers, and historians run past vendor support, and patching requires long change windows.	Initial Access and Impair Process Control	Known flaws in unsupported systems can allow control manipulation with no vendor fix available.
Missing monitoring of control traffic	Networks lack passive sensors or protocol-aware visibility, so unusual commands to controllers go unlogged.	Collection and Impair Process Control	Malicious or faulty commands can persist unnoticed, delaying detection and response during an incident.
Insecure engineering workstation practice	Engineering workstations browse the internet, carry removable media from other sites, or run unmanaged software that can load project files.	Execution and Persistence	A compromised engineering workstation can push altered logic to controllers that operators trust.
Weak backup and recovery of controller configuration	Controller programs and configurations are stored in one place, untested, or without a known-good baseline for comparison.	Inhibit Response Function and Impact	After a fault or attack, recovery may take far longer because no verified configuration exists to restore.

How the assessment changes for industrial control, building automation and remote sites

In manufacturing and process plants, the controllers, historians, engineering workstations and safety systems run processes where a poorly timed scan or a rebooted controller can stop production or create a hazard. Passive discovery is the default: network captures taken from span ports or mirrored switches, reviewed against asset lists and the zone model. Active testing is limited to what the plant owner has approved for each zone, usually against non-production replicas or during a planned outage.

Passive first: Traffic analysis and configuration exports are preferred over live scanning of controllers.
Safety system boundaries: Safety instrumented systems are normally excluded from active testing unless the owner and the safety engineers agree otherwise in writing.
Vendor involvement: Controller and HMI vendors may need to confirm which functions can be exercised without voiding support or triggering a safety review.
Maintenance windows: Active tests belong in a scheduled shutdown with rollback steps, a named operator on site and an agreed stop condition.
Mapping to ATT&CK for ICS: Findings are tied to the matrix's tactics, such as Impair Process Control, so engineers can see which process paths are exposed.

Confirm with plant engineering which zones are safety-rated, which controllers have vendor restrictions on scanning, and who can authorize a stop.

What drives the cost and duration of an OT and ICS security assessment

This table compares the main cost components of an OT and ICS assessment, showing who is paid for what effort, whether it recurs, and what pushes it up or down. DeployOpen does not publish prices, and a quote follows from the written scope, so use the questions in the last column to compare proposals on equal terms.

Cost component	Who does the work and what drives effort	What to ask for in a quote
Sites and zones in scope	Effort grows with each site and each zone boundary reviewed. Each zone adds asset inventory, flow review and interview time with local operators. Usually one-time for the assessment, though re-review is needed after major change.	Named list of sites, zone and conduit diagram, and whether remote or on-site visits are assumed for each site.
Asset types and vendors	Controllers, HMIs, historians, engineering workstations, safety controllers and network devices from several vendors each need different checks and vendor-specific knowledge. Mixed estates take longer to verify and document.	Asset categories included, vendor list, and who on the assessor side covers each platform type.
Depth of configuration review	A baseline review of hardening settings, accounts, services and remote access costs less than a review that compares running configurations against engineering baselines or standards mapped to ISA/IEC 62443 requirements. Deeper review needs more time with engineering staff.	Whether review is document-based, sample-based or full, and which configuration sources are read (exports, live screens or vendor tools).
Passive discovery scope	Passive monitoring of network traffic needs sensor placement, change windows for port mirroring or taps, and analysis time. Longer capture periods and more network segments raise effort and calendar time. Often one-time, with optional recurring monitoring.	Capture duration, segments covered, placement method, and who installs and removes any sensors.
Active test windows approved by the operator	Each approved window needs planning, operator presence, rollback readiness and reporting. Fewer windows means tighter test selection and possibly more findings left unverified. Windows add scheduling time that is often outside the assessor's control.	Number of windows requested, who approves them, criteria for stopping a test, and what is excluded from active testing.
Safety-system and vendor-restricted assets	Safety instrumented systems and assets where the vendor limits testing usually receive document review and passive checks only, or are tested with vendor participation. Vendor coordination, extra approvals and restricted tooling add time and can change the test method.	Written list of excluded or restricted assets, vendor approval status, and the testing method for each restricted asset.
Documentation quality	Current network diagrams, asset lists, policies and change records shorten discovery and interview time. Missing or outdated records push effort into reconstruction, which is usually billed as additional assessor time.	Which documents the client will provide before work starts, their dates, and the assumptions the quote makes if they are missing.
Reporting and evidence	Mapping findings to ISA/IEC 62443 requirements, to ATT&CK for ICS tactics and to the client's compliance or insurer requirements adds drafting and review time. Evidence packs for an auditor add more.	Report format, mapping targets, and whether an evidence pack or executive summary is included.
Retest	A retest checks whether agreed findings are fixed. It is usually a separate, smaller effort after remediation, and it may need another active test window. Retesting is typically one-time per finding set, but continuous monitoring can be added as a retainer.	Retest scope, the time window for retest after remediation, whether retest is included, and what a passed retest produces.

Standards and regulations that expect OT security testing

Few operators commission OT testing for its own sake. Standards, regulators and customers ask for evidence that industrial controls were assessed, and each one frames the scope differently. Knowing which framework drives your request decides which zones, components and tests the assessment must cover.

ISA/IEC 62443 series

The series is organized into four groups: general, policies and procedures, system, and component. Assessments usually start with the system and zone model, then check whether the policies and procedures described in the program match what engineers actually do on the plant floor. Ask your auditor which requirements and security levels apply to each zone and conduit, and record that decision before testing begins so findings can be traced to a specific requirement.

ISA-62443-3-3 system requirements

This part covers system security requirements and security levels, which is where zone boundaries, access control, and monitoring are judged at the level of an assembled control system. A system assessment tests whether the segmentation and access paths designed for each zone hold up in practice, including remote engineering access and data flows from the process network to business systems. Confirm with the auditor which target security level applies to each zone before scoping the test.

ANSI/ISA-62443-4-2 component requirements

This standard defines technical security requirements for individual industrial automation and control system components, such as controllers, engineering workstations, and embedded devices. Component testing checks configuration options, authentication, logging, update mechanisms, and handling of unused services against these requirements. Vendors that supply components often hold this evidence, so ask whether the components in your environment come with documentation that maps to it before paying for repeat testing.

NIST SP 800-82 Rev. 3

Many operators use this guide as the practical OT security reference, and it recommends countermeasures that preserve performance, reliability, and safety. Its scope covers industrial control systems, building automation, transportation systems, and physical access control systems. Use it to structure the assessment around operational risk, and make sure the test plan states how active checks will be limited so that availability requirements are not compromised.

EU Cyber Resilience Act for integrators

Manufacturers and organizations that integrate third-party components into products placed on the EU market have to demonstrate cybersecurity over the product lifecycle. The Commission's FAQ lists penetration testing, firmware analysis, fuzz testing, side-channel analysis, red-team exercises, and network traffic analysis as possible additional tests when components are integrated. Confirm with counsel and a notified body or conformity assessment provider which obligations apply to your product and when they start.

Customer and insurer questionnaires

Operators, utilities, and insurers often send security questionnaires that ask whether OT networks were segmented, tested, and retested after changes. These questions rarely cite a standard, so answers need evidence that can be traced to zones, findings, and remediation dates. DeployOpen prepares that evidence but does not issue certifications or audit reports. Ask each requester which artifacts they accept and whether an independent auditor must review them.

What the client receives and whether it satisfies an auditor or customer

The report is built for two audiences at once: leadership, who need to decide what to fund, and engineers, who need to change the plant. It opens with an executive summary that states the scope, the overall exposure and the decisions required from leadership. The technical body then lists each finding with the affected zone, conduit, asset and the test that produced it. Each severity rating comes with its likelihood reasoning written out, so an engineer or a risk committee can challenge the logic instead of accepting a single label. Findings are mapped to the relevant requirements in ISA/IEC 62443, such as the system requirements in ISA-62443-3-3, and to the tactics in MITRE ATT&CK for ICS that the weakness would support. The remediation plan is ordered by risk reduction and is written around operational constraints, such as which fixes need a maintenance window, which need vendor involvement and which can be done without stopping a process.

Two sections matter most to an auditor or a customer's security team. The first is the record of what was not tested and why, which covers any safety-restricted device, any active test that was deliberately limited, and any zone excluded by the client. The second is the retest result, which shows whether each finding was closed, partly closed or accepted as a risk by the owner. Neither a report nor a letter from DeployOpen is a certification, attestation or audit opinion. Only an independent auditor or certification body can issue those, and DeployOpen does not do so. Before signing a test order, ask your auditor which artifacts they accept for the framework in question, whether they want the full report, a summary or evidence of the zone model, and whether they expect the testing to be performed by a particular kind of assessor.

For customers who require proof of testing without sharing the full report, DeployOpen can provide a letter summarizing scope and results. Its content is agreed in advance, usually covering the period, the assessed scope in general terms, the methodology reference, the number of findings by severity and the retest status. Agree the wording before work starts, and confirm with the customer's security team whether the letter must name the assessor, carry a date range or be signed by a particular person. Keep the detailed findings under the client's control, because they describe weaknesses in systems that run physical processes.

What to check in an OT security provider before you sign

Industrial control work carries physical and safety consequences that ordinary IT testing does not. The cards below cover the provider checks that separate a plant-safe assessment from a risky one, and the written items you should hold the provider to before any work starts. Ask for each of them in the scope document, not in a sales conversation.

Industrial control experience and safety awareness

Ask who will actually run the assessment and what they have done on live plants, not only on office IT. Look for working knowledge of process control, safety instrumented systems, vendor-specific controllers and the difference between a lab rig and a running process. Ask how the team decides when a system is too fragile to touch, and whether a plant engineer reviews the plan before fieldwork. Confirm that the staff named in the proposal are the ones who will attend the site.

Written rules of engagement and stop conditions

The rules of engagement should list which networks, zones and assets are in scope, which techniques are allowed in each, and the time windows for work. Stop conditions matter most: specify the signs that end an activity immediately, such as unexpected controller state changes, alarms, loss of view on a process or rising network latency. Ask who has authority to call a stop and how quickly the team must comply. A provider that cannot describe its stop conditions in writing has not planned for a live plant.

Named safety and operations contacts

Each side needs named people with decision authority: a safety or operations lead at your organization, a plant or shift contact who can halt work, and a provider lead accountable for the test. Confirm escalation paths for out-of-hours events and who holds the authority to approve changes to the plan on the day. Named contacts also let you verify that the people who approved a test are the people who received its results.

Passive discovery without disrupting traffic

Ask the provider to describe how passive discovery works on your network: which span or tap points are used, whether any active probes are sent, and how traffic is copied without affecting controllers. Passive methods are the usual starting point in OT because they build an asset and communication inventory without generating load. Ask for the protocols the team expects to see, and for confirmation that no scanning is planned unless it appears on the approved list of active steps.

Reporting mapped to ISA/IEC 62443 and ATT&CK for ICS

Ask for findings that map to the zone and conduit model and to the security requirements in ISA-62443-3-3, and that reference technique IDs from the MITRE ATT&CK for ICS matrix. Mapped reporting lets your engineers, auditors and customers trace each finding to a control gap and a plausible adversary behavior. Request a sample report structure before signing, and confirm which edition of each framework the provider uses so the mapping can be checked later.

Retest and remediation support scope

Clarify what happens after the report is issued. Some providers include a retest of confirmed findings, others charge for it, and remediation advice is often separate from remediation work. Ask whether retest covers only the findings or also the zones touched by fixes, how long retest access to the site remains available, and whether the same safety controls apply to retest work. Agree these terms in writing so the retest budget is not a surprise.

Data handling for captures and inventories

Network captures and asset inventories reveal how your plant is built, which makes them sensitive. Ask where captures are stored, who can access them, how long they are kept, how they are encrypted, and how they are destroyed at the end of the engagement. Confirm whether the provider will work on air-gapped or segregated systems and whether any data leaves your environment. Get these terms in the contract, not only in a security questionnaire.

Insurance and liability terms

A test that disrupts a process can cause losses well beyond the cost of the assessment. Ask the provider to state its professional indemnity and liability cover in writing, how liability is capped, and whether it extends to physical damage or production loss caused by the team's actions. Confirm which party is responsible for backups, change approvals and vendor notification. Have your legal and insurance teams review these terms before the scope is signed.

How long, how much effort and what it needs from our team

What drives the cost of an OT and ICS security assessment?

The cost follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of sites, zones and conduits reviewed, how many control system components and vendor platforms are in play, whether passive discovery runs across live networks or only on captured traffic, and how much active testing is agreed for test or staging systems. Architecture review against ISA/IEC 62443 and mapping findings to MITRE ATT&CK for ICS add reviewer time, while a narrow configuration review of a single plant costs less. Ask for a quote that lists each component, the assumptions behind it, and any work that recurs, such as retesting.

How long does an OT security assessment take?

Duration depends on how many sites, zones and asset types are in scope, how quickly the operations team can supply documentation, and how many change windows are available for any on-site or active work. Scheduling around plant shutdowns and safety reviews often sets the pace more than the testing itself. No duration is fixed here, so confirm the timeline, its milestones and the dependencies on your side in the written scope before work starts.

What does the operations team need to provide before testing starts?

The assessment depends on accurate inputs, so expect to supply network diagrams for each site, an asset inventory covering controllers, HMIs, historians and engineering workstations, and a list of remote access paths and vendor connections. Also provide approved change windows, a named contact for each process or safety system, and the escalation path if a test affects a running process. Early access to existing security policies, previous assessment reports and firewall rule sets shortens the review considerably.

Can our team run passive discovery itself, and what skills does it need?

Yes, passive discovery can be run by your own staff if they can deploy a monitoring tool on a mirror port or tap without injecting traffic into control networks. They need working knowledge of industrial protocols, switch configuration and asset classification, and someone must be authorized to approve the placement with plant engineers. DeployOpen can plan the discovery approach, review the captured data and interpret it against zone boundaries. Confirm in the written scope which parts you will run and which DeployOpen will perform.

Can active testing run while the plant is in production?

Active testing should not run against production control systems unless the process owner and safety team have explicitly approved it in advance. Carefully limited active checks are usually performed on test benches, staging copies or during planned maintenance, and the scope should name which systems are excluded. Any approved activity needs a rollback plan, a clear stop condition and a person on site who can halt it. Agree these limits in writing before any traffic is sent to a live network.

How is retesting priced and scheduled?

Retesting is typically a separate, scoped piece of work that checks whether the agreed remediations were implemented and effective. Its cost depends on how many findings are retested, whether the changes require a new round of configuration review, and whether it can be done remotely or needs a plant visit. Schedule retesting after the client has confirmed fixes and the change windows are available, and ask for the retest terms in the original written scope. Ongoing testing can also be arranged as a retainer.

Does the assessment output satisfy an ISA/IEC 62443 audit?

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. The assessment output can support your own gap analysis and give an independent auditor or certification body the zone, conduit and configuration evidence they need. Whether it meets the auditor's expectations for a given security level depends on that body's process, so confirm the expected evidence format with them before scoping the work. For the standard's structure, see the ISA/IEC 62443 series overview.

How DeployOpen scopes, tests, reports and retests OT environments

DeployOpen is a Chainscore Labs company that runs security testing for industrial and connected environments, planning each assessment around safety and uptime from the first conversation. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work begins.

How we scope

Written scope names the sites, zones, control systems and conduits that are in and out of the assessment.
Scope records which activities are passive only and which, if any, are approved active tests and when they run.
Plant operators, safety engineers and control system vendors confirm constraints, maintenance windows and rollback steps before testing starts.

How we build

Passive discovery and architecture review map assets, communications and zone boundaries against ISA/IEC 62443 requirements.
Configuration review checks controllers, engineering workstations, remote access and network segmentation against agreed security levels.
Limited active testing is mapped to MITRE ATT&CK for ICS tactics and techniques, and only runs where the written scope and operators allow it.

How we hand over

Deliverables include the agreed findings, evidence, affected assets and recommended changes, prioritized with operational impact in mind.
Reports map findings to ISA/IEC 62443 requirements and ATT&CK for ICS techniques, so engineering and compliance teams can use them.
Clients receive a debrief with operations and engineering staff to agree remediation owners and sequencing, plus a retest scope.

How we support

Retesting checks whether agreed remediations are in place, using the same scope and limits as the original assessment.
Ongoing support, periodic reassessment and continuous testing are available as retainers, scoped in writing.
Ask for a written quote that lists assessment activities, retest rounds and any support hours before commissioning work.