Operators at a control room console with process displays and a plant overview screen
Where the decision sits
Authority boundary No production-impacting action is taken by the security operations centre. The SOC establishes what is happening and what it means for the process. The decision to act on the plant belongs to the people accountable for it.

The escalation path an alarm actually travels. Select a stage to see who acts, and what they are not permitted to do.

Scope

Four capabilities, and the two disciplines that make them work in OT.

The first four are what the service does. The last two are why a plant gets value from it rather than an inbox of alerts nobody can act on.

01

Monitoring built around the process, not a generic baseline

Detection is designed from your operational consequence model: which functions must keep running, what normal traffic looks like between which zones and conduits, which engineering actions are expected and which are not. A configuration download to a controller outside a maintenance window means something specific in a plant; in an enterprise baseline it means nothing at all. Collection is passive throughout — network observation, log and event sources, and existing platform telemetry. We do not scan production networks, and we do not place anything in line with a control path.

02

Security control effectiveness, measured rather than assumed

Controls degrade quietly. Firewall rules accumulate exceptions, a sensor stops receiving from a segment after a switch replacement, a log source drops out, an allow-list drifts after a vendor visit, a backup job fails silently for months. Shield tracks whether each control in scope is still doing what it was installed to do, and reports the gap the week it opens rather than at the next assessment. Where a control has stopped working, you get the operational consequence of that gap, not just the technical finding.

03

Firewall management — policy lifecycle, not rule editing

Rule base ownership across the IT/OT boundary and between industrial zones: change request review against a documented policy intent, business and engineering justification recorded per rule, rule hygiene and removal of what is no longer needed, and object and naming discipline so the policy stays readable to whoever inherits it. Every change is raised, reviewed and implemented inside your change control and within your maintenance windows. We propose and prepare; your process approves.

04

Active Directory management for the OT domain

The OT domain is frequently the single most consequential and least maintained system on a plant network. Shield covers privileged account inventory and review, service account governance including the accounts that exist because a historian or an HMI needed one years ago, group policy baseline and drift, authentication and logging configuration, and the trust relationship with the enterprise domain. That last item is where most IT/OT exposure actually lives, and it is a design decision rather than a setting.

05

Escalation and incident coordination with decision rights agreed in advance

Who is called, in what order, within what time, and who is permitted to decide what — written down and tested before it is needed. When something is detected, you receive the observation, the affected operational function, the credible interpretations including the operational ones, and containment options with the production consequence of each option attached. The decision belongs to operations. A service that quietly isolates a segment at three in the morning is not a mature service.

06

Reporting, documented blind spots and continuous tuning

Coverage is stated as what is monitored and, explicitly, what is not — unmonitored segments, serial links, air-gapped cells, systems whose vendor agreement prevents log collection. Named blind spots can be funded and closed; assumed coverage cannot. Detection logic is tuned on a standing cadence as the plant changes, because a turnaround, a new line or a migration will invalidate a baseline that nobody revisits.

An alert nobody is authorized to act on is a record, not a defense.

Coverage models

Two coverage models. The same four capabilities in both.

Neither model is the better product and neither is a stepping stone to the other. Whether you run an in-house OT SOC, buy OT managed security services, or feed industrial context into an existing IT SOC, the question is the same: how quickly the loss or manipulation of a critical function becomes an operational or safety event, and who is available to decide when it does.

What it covers

  • Analyst attention during your working day, in your site's time zone, on the working days agreed in the service definition.
  • Monitoring, control effectiveness measurement, firewall policy management and OT Active Directory management, all four delivered in full.
  • Detection continues to run and events continue to be collected outside those hours. What pauses is the analyst reviewing and escalating them, not the collection.
  • Queued events are triaged at the start of the next covered period, with severity ordering applied so the oldest is not automatically the first.

Who it suits

The gap is real and we state it in the service definition rather than in a footnote: an event beginning on a Friday evening may not be reviewed by an analyst until Monday morning. Whether that is acceptable is a consequence judgment your operations leadership makes, not a judgment we make for you.

  • Operations where the loss of a critical function takes hours rather than minutes to become a safety or production event, and where a process upset would be noticed by shift staff long before a security analyst saw it.
  • Sites that do not run continuously, or that run unattended overnight with limited change activity.
  • Organizations with no one available to receive a call at three in the morning. Round-the-clock detection escalating to a phone nobody answers buys the appearance of coverage rather than coverage.
  • Estates where the honest first priority is monitoring quality and blind-spot closure during working hours, before extending the clock.

What it covers

  • Analyst attention at every hour, including nights, weekends, public holidays and the periods when industrial estates are least staffed and most changed.
  • The same four capabilities as 8×5. Nothing is withheld from the lower model and nothing additional is unlocked by the higher one.
  • Escalation against the agreed matrix at any hour, which only produces value where your side of that matrix is also staffed at any hour.
  • Turnaround and shutdown periods covered as they run, when vendor access, temporary connections and out-of-hours engineering activity are all at their peak.

Who it suits

What 24/7 does not change: containment authority still sits with operations, no analyst makes a production decision at any hour, collection remains passive, safety systems remain out of scope, and firewall and directory changes still run through your change control and your maintenance windows. A faster clock does not create authority that the service was never designed to hold.

  • Continuous processes where minutes matter: operations in which loss or manipulation of a function moves toward a safety, environmental or major production consequence faster than a working-hours review cycle can respond.
  • Organizations with their own people on shift who can receive a call and act on it, because escalation is only as fast as the slowest link in it.
  • Regulated entities whose obligations require demonstrable detection and response capability outside working hours.
  • Multi-site estates spanning time zones, where any single working day leaves another region uncovered.

Coverage and authority

You choose the coverage. Operations keeps the authority.

Both coverage models are genuinely available and both are properly staffed. Which one is right is a consequence question, not a commercial one.

  • 8×5 or 24/7 — agreed in the service definition, not sold as an upgrade path
  • The deciding factor is consequence — how quickly loss or manipulation of a function becomes an operational or safety event, and whether your own people are on shift to receive a call
  • Containment authority stays with you — options are presented with operational impact attached; no analyst makes a production decision
  • Passive collection only — no active scanning of production networks at any point
  • Safety systems out of scope — SIS is not monitored as a cybersecurity testbed
  • Changes run through your change control — firewall and directory work inside your windows and vendor agreements

Fit

When this is the right service — and when it is not.

Use InnovAKT Shield when

  • You have monitoring capability deployed but nobody with industrial context watching it.
  • Your IT SOC receives OT alerts it cannot interpret, and escalates either everything or nothing.
  • Firewall rules and OT domain accounts have drifted, and no one owns the policy intent.
  • You need continuous assurance that controls still work, not a point-in-time statement each year.
  • Your team can cover working hours but not nights, weekends, turnarounds or holidays.
  • A regulator, insurer or customer expects demonstrable detection and escalation capability.

Do not use InnovAKT Shield when

  • You expect the service to make production decisions. Containment authority stays with operations, by design and in the contract.
  • You have no asset or architecture visibility yet. Monitoring an environment nobody has mapped produces noise — start with GoSecure™.
  • You need forensic investigation, threat hunting or on-site incident attendance. Those sit outside this service.
  • Nobody internally will own the escalations. A service with no counterpart on your side becomes a reporting exercise.
  • What you actually need is decision authority and governance — see OT CISO Advisory.

Framework alignment

Detection designed in one language. Reported in another.

The service is structured around ISA/IEC 62443 — zones, conduits and the capability requirements your engineering teams and industrial vendors already work to. That is what makes a detection explicable to the people who have to act on it.

Detection logic is designed and documented against MITRE ATT&CK for ICS, so coverage can be discussed as specific adversary techniques against specific industrial functions rather than as a product feature list. Reporting is structured to NIST CSF 2.0 where leadership already reports in that language.

NERC CIP evidence requirements are built into the reporting only where you are a registered entity. Mapping is scoped to what actually governs you — adding frameworks that do not apply produces pages, not assurance.

Outcomes

What is different in the operation afterwards.

Alerts that reach the right person

Escalation paths and decision rights agreed in advance and exercised, so a detection at two in the morning produces a phone call to someone with authority rather than a ticket waiting for Monday.

Control drift caught in weeks, not years

A failed log source, an orphaned firewall exception or a stale privileged account surfaces as a reported gap with its operational consequence, instead of appearing in the next audit.

Coverage you can state accurately

A written, current picture of what is monitored and what is not. Being able to name your blind spots is what allows them to be funded and closed.

A team that keeps its own capability

Your people stay in the escalation path and in the service reviews, so knowledge of the environment accumulates inside your organization rather than only inside ours.

Deliverables

What you receive, in writing.

Exact contents and cadence are agreed in the service definition. These four are present in every Shield service.

01

Service definition and escalation matrix

Coverage model, monitored scope, data sources, severity definitions, contact tree with named roles, response times per severity, and the explicit statement of which decisions belong to whom during an incident. Signed by both sides before go-live.

02

Monthly service report

Events detected and their disposition; what was escalated, to whom, how quickly, and what the outcome was; which events turned out to be operational rather than adversarial and what that revealed; control effectiveness status with any gap opened or closed; firewall changes reviewed, implemented and rejected; privileged and service account changes in the OT domain; open items with owners and dates.

03

Detection coverage and blind-spot register

Monitored zones, conduits and sources mapped to ATT&CK for ICS techniques, alongside the named list of what is not covered, why, and what closing each gap would require. Updated as the environment changes.

04

Quarterly service review

A working session rather than a document: tuning decisions and their effect, escalation performance against the agreed matrix, changes in the plant that alter the baseline, recommended adjustments to scope or coverage, and the decisions needed from you.

Engagement process

Five steps from definition to steady state.

Onboarding duration depends on site count, data source availability and change-control cadence. It is established during service definition, before any commitment is made.

Step 01

Service definition and coverage selection

Scope, sites, systems and data sources agreed in writing. Coverage set at 8×5 or 24/7 based on how quickly a loss of function becomes an operational or safety consequence and on whether your own people are available to receive a call outside working hours. Severity definitions, escalation matrix, decision rights and exclusions documented and signed.

Step 02

Onboarding and connection

Passive collection established, log and event sources connected, firewall and directory administrative access agreed under your access governance, and the environment documented as found. Conducted inside your change control and maintenance windows, with vendor agreements checked before anything is connected.

Step 03

Baselining

Normal operating behavior observed and characterized with your engineering team: expected traffic between zones, routine engineering activity, maintenance patterns and vendor access windows. Firewall policy intent and the OT domain account and group policy position documented as a baseline that future drift can be measured against.

Step 04

Go-live under agreed escalation

The service begins at the agreed coverage, with a defined stabilization period in which detection thresholds are tuned against real operating conditions and the escalation path is exercised deliberately rather than discovered during an incident.

Step 05

Continuous improvement

Standing tuning cadence, blind-spot register maintained as the plant changes, control effectiveness tracked between assessments, and quarterly review with your team to adjust scope, coverage and priorities. Turnarounds, migrations and new lines are treated as baseline events, because they are.

Questions we are actually asked

What operations asks before an outside service sees the network.

Will you ever take an action on our network?

Not one that changes the state of your process. When something is detected you receive the observation, the operational function affected, the credible interpretations including the ones that turn out to be a maintenance activity, and the containment options with the production consequence of each attached. Operations decides.

Firewall and OT directory work is the one place we prepare changes, and those are raised, reviewed and implemented inside your change control and your maintenance windows. We propose and prepare. Your process approves. A service that isolates a segment at three in the morning on its own authority is not a mature service, whatever its response time looks like.

We already have an IT SOC. Why would we pay for a second one?

Usually you would not be buying a second one. The common position is an IT SOC receiving OT telemetry it cannot interpret, so it either escalates everything and is ignored, or filters heavily and misses the events that matter. Shield can run as the industrial context layer feeding your existing SOC rather than as a parallel service, which is the usual answer to the in-house OT SOC versus managed security services question.

If your SOC already has engineers with process knowledge, a detection set built from your consequence model, and an escalation path that operations has agreed, then what you need is tuning and a blind-spot review, not a managed service. We will say that rather than sell around it.

What exactly are you collecting, and does our process data leave the site?

Data scope is settled in the service definition before go-live: which sources are collected, what is retained, how long, where it is stored, who within our team can see it, and what happens to it when the service ends. Collection is passive throughout, with nothing placed in line with a control path.

Where residency or contractual restrictions mean data cannot leave the site or the country, the collection and analysis tier can sit locally with only the working views leaving. That changes the commercial model and the onboarding effort. It does not change the capability, and we would rather adjust the architecture than ask you to relax a restriction you are right to hold.

What happens if you miss something?

Two different situations, and we separate them deliberately. If the event occurred in a segment, link or system on the blind-spot register, the coverage limit was declared in writing before go-live and reported every month since. That is a funding decision that was left open, not a detection failure, and pretending otherwise would make the register worthless.

If it occurred in a monitored path, it is a failure of our detection logic or our triage. It goes into the service review with the reasoning, the logic is changed, and the change is recorded. No monitoring service detects everything, and any provider claiming complete visibility of an industrial estate is describing a sales position rather than an engineering one.

Do we have to buy a platform from you?

No. We hold no resale margin and no referral position in any product. Shield frequently runs on capability you already own and have not fully configured, which is a cheaper and faster starting point than replacing it.

Where a genuine gap exists, the requirement is written so you can tender it competitively. You keep the license relationship, which also means you keep the ability to change service provider without changing your platform.

Our own team will read this as being replaced.

It is a fair concern and it is worth addressing directly with them rather than around them. Your people stay in the escalation path, sit in the quarterly service reviews, and hold the operational knowledge the detection logic is built from. We cannot tune a baseline for your plant without your engineers, and we do not try to.

There is a version of this service that keeps the customer out of the loop and reports monthly. It is easier to run and it leaves the organization weaker each year, because the knowledge of the environment accumulates in the supplier. If the requirement is that nobody internally has to be involved, we are the wrong provider.

Next step

Start with the coverage conversation, not the platform.

Before scope or tooling, the useful question is how long your operation can tolerate the loss of a critical function, and who is available to decide when it happens. That answer sets the coverage model, and most of the rest follows from it.

  • Coverage agreed, not upsold — 8×5 or 24/7, chosen on consequence
  • Four capabilities, fully delivered — monitoring, control effectiveness, firewall management, Active Directory
  • Production authority stays with you — every containment option carries its operational impact
  • Vendor-independent — nothing we recommend earns us a margin

Questions buyers ask

The three things we are asked before we start.

What is InnovAKT Shield?

InnovAKT Shield is a packaged OT cybersecurity program for organizations that need capability quickly and do not have the internal scale to build it from parts: assessment, architecture, implementation, monitoring and governance delivered as one coordinated program with a single accountable lead.

Who is InnovAKT Shield designed for?

Mid-sized asset owners, multi-site operators and organizations under a new regulatory or customer obligation who need a defensible program in months rather than years, and who would otherwise be coordinating four vendors and an internal team themselves.

How is a packaged program different from a series of projects?

Sequence and ownership. In a packaged program the assessment is written to feed the architecture, the architecture is written to be implemented, and the monitoring is designed around what was actually built — with one team accountable for the outcome rather than each party accountable for a deliverable.