Deployed, configured as intended, observed working, proven under test. Most control failures we find are not missing products — they are a gate that was never closed. Select a control to see where it usually stops.
Scope
Six areas of work, in this order.
Verification moves from the least intrusive evidence to the most, and stops at whatever boundary was agreed. Nothing progresses to a later area until the earlier one has been documented.
Configuration and coverage against design intent
Every control is measured against what it was specified to do, not against a generic checklist. Firewall policy, zone definitions, hardening baselines and monitoring scope are compared with the original design, and the gap between the two is documented with the configuration evidence that demonstrates it. Drift is normal in a running plant; undocumented drift is the finding.
Segmentation enforcement, confirmed rather than assumed
We establish what a zone boundary actually enforces: which flows are permitted by policy, which are permitted by an exception nobody remembers, and which paths bypass the boundary altogether through dual-homed hosts, wireless, maintenance laptops or legacy routing. Confirmation comes from configuration, routing state and observed traffic, within the agreed rules of engagement.
Monitoring and detection, verified end to end
A detection that fires into an unattended console is not a control. We follow the full path: sensor coverage, event generation, collection, rule logic, alert presentation and — the step most often untested — the human escalation. Who receives it, at what hour, with what industrial context, and what they are authorized to do next.
Backup and recovery, actually exercised
Backup jobs that complete successfully are evidence of a backup, not of a recovery. We review scope, isolation and retention, then exercise restoration of representative controller programs, engineering workstation images and configuration sets on spare or bench equipment during agreed windows. The measure is whether the operation could be restored, and how long it would take.
Identity, privileged access and remote paths
Accounts, shared credentials, privilege levels and remote entry routes traced through to the systems they can reach. Vendor, integrator and OEM access is verified against what was authorized: whether the route is the designed one, whether privilege matches the task, and whether access granted for a completed engagement was genuinely revoked.
Assurance statement and remediation path
Findings converted into two outputs: a formal statement of what was verified and what was not, and an ordered remediation path with owner, dependency and operational impact attached to each item. Written so the first can be handed to an auditor or insurer and the second can be funded and executed without translation.
What was not verified is the half of the statement that matters.
How we work on site
Verification built for a running plant.
The reasonable first question about this service is how we verify controls on a production network. The method, and the safeguards around it, are written into scope before anything begins.
- OT-native by design — OT-native cybersecurity solutions on the production network, configuration review and evidence collection carry the work
- Written rules of engagement — scope, timing, method, abort criteria and named abort authority agreed in advance for every active step
- Safety systems out of scope — SIS is never a test target and is not used as a verification path
- Stop authority stays with operations — any nominated person can halt a test, and the test stops
- Recovery tested off the running process — restoration exercised on spare or bench equipment, never on a controller mid-run
- Technique-informed, not technique-driven — MITRE ATT&CK for ICS structures what we look for; it is never a justification for interfering with a live process
Fit
When this is the right engagement — and when it is not.
Use ControlPulse™ when
- Controls are deployed and nobody in the organization can evidence what they cover.
- An insurer, auditor, regulator or major customer has asked for evidence that controls are effective, not merely present.
- A cybersecurity program has completed and leadership wants independent confirmation before it is closed out.
- You have inherited controls you did not specify, through acquisition, handover from an integrator, or a change of internal ownership.
- Detection exists but has never been proven to reach a person who is authorized and able to act on it.
- Backups run and complete, and a realistic restoration has never been performed.
Start with another service when
- No credible baseline of operational risk exists. Verification needs something to verify against — start with GoSecure™.
- The controls in question have not been built yet. We design and implement them through AKTSecure™, then verify the result.
- An incident is in progress. Email info@innovakt.com with “OT incident” in the subject rather than using the form. We confirm quickly how we can support, working under your operational authority, and verification follows once the plant is stable.
- What you need is continuous coverage rather than a point-in-time verification — see InnovAKT Shield™.
Framework alignment
Verified against the baseline. Reported in the language leadership uses.
ISA/IEC 62443 provides the control baseline. Zones, conduits, security levels and system requirements give each verification a defined expectation, so a finding states the distance between the control as specified and the control as operating rather than an opinion about good practice.
MITRE ATT&CK for ICS structures technique coverage. It tells us which adversary techniques the deployed controls would plausibly detect or impede, and where coverage is thin — used as a map for safe, technique-informed verification, never as grounds for exercising a technique against a live process.
NIST CSF 2.0 is used where leadership and the board already report in that language, so verification results land in an existing governance conversation instead of creating a parallel one. No customer is verified against every framework we hold. Scope names the ones that actually govern your organization.
Outcomes
What is different in the organization afterwards.
Evidence in place of assumption
Statements about coverage that rest on tested, recorded results, so a board conversation about protection becomes a discussion of facts rather than confidence levels.
A stated boundary of assurance
A clear record of what was not verified and why. Auditors, insurers and boards want that half of the statement as much as the first, because it defines where residual risk sits.
Detection that reaches a person
Escalation proven through to a named recipient with the authority and industrial context to decide what happens next, rather than assumed to work because the platform is configured.
Remediation that is specific
Corrective work scoped to observed gaps in your environment, with owners and dependencies attached, rather than a generic improvement list that could apply to any plant.
Deliverables
What you receive, in writing.
Exact contents are agreed in scoping. These four are present in every engagement.
Coverage analysis
Each control set compared against its design intent and its 62443 baseline, with configuration evidence attached and undocumented drift identified by system and by zone.
Verification evidence pack
Every test performed, the method used, the window it ran in, the authority who approved it and the result observed — assembled so a third party can follow the reasoning.
Assurance statement
A formal record of what was verified and what was not, with the boundary of assurance stated explicitly. Written to be handed to an auditor, insurer or board without interpretation.
Prioritized remediation path
Ordered corrective work with owner, dependency, effort and operational impact per item, sequenced so the highest-consequence gaps close first.
Engagement process
Five steps, agreed before the first one begins.
Duration depends on the number of control sets in scope, site count and the availability of maintenance windows. Scoping establishes it before any commitment is made.
Baseline and design intent review
We establish what each control was intended to achieve, from design documentation, change records and conversations with the people who built and operate it. Verification without an agreed intent produces observations rather than findings.
Rules of engagement
Scope, method, timing, windows, exclusions, abort criteria and named abort authority documented and signed before any verification begins. Safety systems are excluded in writing. Nothing active is attempted outside this document.
Verification and evidence collection
Configuration review, network visibility through OT-native cybersecurity solutions on the production network, log and alert analysis, access record review and site walkdowns. The majority of findings are established here, with methods agreed with operations.
Controlled verification within agreed windows
Where active confirmation is required — a boundary test, an escalation exercise, a restoration on bench equipment — it runs inside an agreed window, with your operations team present and stop authority held by the plant. Each step is recorded as it is performed.
Assurance statement and remediation handover
Findings validated with your technical team before writing, then the assurance statement and remediation path delivered in a working session that assigns owners and confirms sequence. Your team does not see the content for the first time in front of leadership.
Questions we are actually asked
The questions that decide whether this engagement can run at all.
Are you going to break something to prove a point?
No. Most of the evidence comes from configuration review, OT-native cybersecurity solutions built for production networks, log and alert analysis and access records. Where active confirmation is required, it runs inside an agreed window under written rules of engagement, with your operations team present and a named person who can stop it.
Safety systems are excluded in writing and are never a test target. Restoration is exercised on spare or bench equipment, never on a controller mid-run. Where a step needs different conditions, we agree them with you: your spare or bench equipment, a vendor test system or a later window. The assurance statement records how each step was verified.
What if you find that the controls we just paid for do not work?
That is a common outcome rather than an unlikely one, and it is usually drift rather than a supplier failing. A control commissioned correctly two years ago will have been touched by a switch replacement, a patch cycle, a vendor visit and a turnaround since.
We report it with the configuration evidence attached, and we do not soften it, because a verification you can argue with in a boardroom is not a verification. Findings are written so the party who built the control can act on them rather than defend against them, which matters when that party is still under contract with you.
Our board wants a clean statement. Can you give us one?
Only where the evidence produces one, and never by leaving out the boundary. Every assurance statement we issue records what was verified and what was not, with the reason. That is not a hedge. It is the part an insurer, an auditor or a regulator reads most carefully, because it defines where residual risk sits.
Where the gaps are what stand between you and a clean statement, we can close them through AKTSecure™ and verify again. The re-verification states where InnovAKT delivered the remediation, so the statement your board receives is both clean and transparent.
Can you test our detection without telling the team being tested?
Within limits, and the limits are not negotiable. Analysts and responders can be unaware that a particular activity is a test, because that is the only way to verify an escalation path realistically. Operations cannot be unaware that a test window is open.
Someone with plant authority always knows what is running, when, and how to stop it. An unannounced exercise against a live industrial environment risks an operator making a correct and consequential decision about an event that was never real.
We cannot give you a maintenance window in this period.
Then the engagement narrows rather than stops. Configuration and coverage analysis, policy review, access and privilege tracing and detection logic review all proceed without one, and they carry a substantial share of the findings.
What does not proceed is boundary confirmation that requires a controlled test and restoration exercises on bench equipment. Those are deferred, and the assurance statement says so plainly. A narrower verification, honestly labeled, is worth more than a broad one that quietly rests on assumption.
How is this different from a penetration test?
A penetration test asks what an attacker could achieve. This asks whether each control does what it was specified to do. They are different questions and they produce different evidence, and in an industrial environment they carry very different risk to the process.
MITRE ATT&CK for ICS structures what we look for, so coverage can be discussed as specific techniques against specific functions. It is used as a map for safe verification and never as a justification for exercising a technique against a live process.
Next step
Start with the control you rely on most.
Verifying a single control set — one zone boundary, one detection path, one recovery procedure — establishes the method and the level of rigor before anything is committed across the estate. It also answers the question leadership is usually asking first.
- Rules of engagement in writing — scope, timing and abort criteria agreed before any active step
- Safety systems excluded — SIS is never a verification target
- Stop authority with operations — the plant can halt any test at any moment
- The gaps stated, not omitted — the assurance statement records what was not verified
Questions buyers ask
The three things we are asked before we start.
What is ControlPulse™?
ControlPulse™ is a scoped OT security control validation engagement. It verifies whether the controls already in place perform as intended and produces recorded evidence, a clear statement of what was and was not verified, and prioritized corrective actions. Continuous managed coverage is provided through InnovAKT Shield™.
Does ControlPulse™ provide continuous OT monitoring?
ControlPulse™ checks monitoring coverage, detection logic and escalation as a verification engagement. Continuous OT monitoring is delivered through InnovAKT Shield™, and the ControlPulse™ findings become its starting baseline.
Does ControlPulse™ replace our internal security team?
No. We work with your security, engineering, and operations teams to establish each control’s intended purpose, agree the verification boundary, and review the evidence. Your team receives the findings and corrective-action priorities. Operational decisions and authority remain with the asset owner.