SIS Cybersecurity: Building a Cyber Assurance Case

Direct Answer

Safety instrumented system cybersecurity needs an assurance case that connects a bounded safety claim to arguments and evidence about independence, access, configuration integrity, authorized change, proof testing, bypass governance, dependencies, and recovery. Cybersecurity supports functional safety; it does not replace hazard analysis or safety validation.

Key Takeaways

A checklist cannot establish confidence in a specific safety function.
Logical separation may still depend on shared people, tools, identity, power, time, or vendors.
Cyber evidence should be added without distorting the safety lifecycle.
Temporary bypasses and force states require time-bound governance and restoration proof.
Limitations and counter-evidence should remain visible.

A Checklist Cannot Establish That a Specific Safety Function Remains Trustworthy

Safety instrumented systems operate within a functional-safety lifecycle, but their trust can depend on identities, engineering workstations, vendor tools, networks, power, time sources, configuration repositories, certificates, procedures, and personnel. Logical separation does not remove those dependencies.

Cybersecurity should not claim to replace hazard analysis, safety validation, proof testing, or engineering authority. Its role is to protect confidence in access, configuration, change, independence, evidence, bypass control, and recovery. Those claims should be made explicitly and supported by an argument and current evidence.

A cyber assurance case provides that structure. It states the safety-related claim, exposes dependencies, records supporting and contrary evidence, identifies limitations, and shows who is authorized to accept the remaining uncertainty.

Expose dependencies

Map shared engineering workstations, identity, networks, power, time sources, vendor tools, repositories, procedures, and personnel. Independence should be assessed against real dependencies, not only network diagrams.

The dependency analysis should include shared engineering laptops, vendor remote service, identity, time synchronization, power, network management, configuration storage, certificates, maintenance procedures, and specialist availability. A shared dependency can weaken independence even when the SIS network is segmented.

Control safety-related change

Govern logic, firmware, parameters, force states, certificates, engineering sessions, and approved sources. Link cybersecurity evidence to the existing management-of-change and functional-safety process.

Join proof testing with cyber evidence

Add relevant access, configuration, communication, recovery, and evidence-integrity checks without replacing the safety test objective. Record defects and limitations separately.

Cyber evidence should complement the safety test objective. Relevant additions may include the identity and device used, configuration comparison, communication state, bypass record, authoritative source, and restoration evidence. The test should not be distorted into a generic security exercise.

What Makes Cyber Evidence Relevant to a Safety Assurance Argument

Cyber evidence is relevant when it supports a proposition needed by the safety claim. Identity and session records may support the proposition that only authorized personnel changed logic. Configuration comparison may support the proposition that the final state matches the approved source. Dependency analysis may support the proposition that independence assumptions remain credible. Bypass and restoration records may support the proposition that the function returned to the intended operating state.

Evidence that is impressive but unrelated to the claim should not increase confidence. An enterprise vulnerability scan, generic security certification, or network diagram may provide context but cannot establish the state of a specific safety function. The case should explain the relationship between each evidence item and the proposition it supports.

Freshness matters because safety-related trust can change through maintenance, supplier updates, workstation replacement, identity migration, network redesign, or temporary bypass. The assurance case should identify which events invalidate evidence and require revalidation. This avoids carrying forward a conclusion after the conditions that supported it have changed.

Independent challenge should test both the supporting argument and plausible counter-evidence. Reviewers should ask what shared dependency, undocumented change, unclosed temporary state, or recovery weakness could invalidate the claim. The authorized owner then decides whether the case is supported, conditionally supported, or not supported.

Assurance Case Governance and Revalidation

The assurance case needs an owner, reviewer, acceptance authority, evidence custodians, and a revalidation calendar. The owner maintains the claim and argument; custodians maintain source evidence; reviewers challenge the reasoning; the authorized safety owner accepts the conclusion and limitations.

Revalidation should be event-driven as well as periodic. Logic or firmware change, proof-test defect, bypass, workstation replacement, supplier-tool update, identity migration, network redesign, certificate change, incident, or recovery exercise can change the evidence boundary. The case should identify which event reopens which proposition.

A case should also show closure discipline. Corrective actions are complete only when new evidence supports the proposition that was previously weak. Updating a procedure or buying a tool does not close an assurance gap unless the relevant condition is observed and accepted.

The Acceptance Decision

Acceptance should state whether the claim is supported, conditionally supported, or not supported. Conditional support requires the limitation, interim control, owner, expiry, and evidence needed for full support. The decision should be signed by the appropriate safety authority and reviewed after any trigger event. This makes uncertainty governable without converting it into a generic risk score.

A Clear Boundary for the Case

The case should name the safety function, operating mode, asset and dependency boundary, evidence period, and assumptions. It should not be generalized to other functions or sites without confirming that the same dependencies, configuration, change controls, and evidence remain valid.

CyberTech Intelligence Perspective

CyberTech Intelligence’s perspective is that a safety-system cyber assessment should be organized as a claim, argument, and evidence case. This prevents a list of controls or certifications from being interpreted as proof that a particular safety function remains dependable in its actual environment.

The assurance case should preserve counter-evidence. If a vendor tool depends on shared identity, a proof-test record cannot be reconciled with the authoritative logic, or a bypass history is incomplete, the limitation should remain visible until an authorized owner accepts or corrects it.

The conversion value is a bounded cyber-safety review that produces one defendable assurance case, a dependency and evidence map, and prioritized corrections around access, change, configuration, bypass, proof testing, and recovery.

CyberTech Intelligence SIS Cyber Assurance Case

The case connects the safety claim to cyber-relevant dependencies, evidence, limitations, and acceptance.

Assurance element	What it must contain	Decision value
Claim statement	Hazardous condition, safety function, operating assumptions, demand mode, accountable safety owner	Defines exactly what trust claim is being evaluated.
Argument map	Why access, independence, configuration, change, testing, and recovery evidence support the claim	Makes the reasoning reviewable rather than implied.
Dependency case	Shared networks, tools, identity, power, time, vendors, repositories, procedures, personnel	Exposes conditions that can invalidate logical separation.
Safety change evidence pack	Authorized source, logic/firmware/parameter change, identity, session, test, rollback, final baseline	Shows whether safety-related change remained controlled.
Configuration integrity case	Known-good source, comparison, variance investigation, approval history, restore evidence	Protects confidence in the intended safety logic and settings.
Proof-test evidence link	Relevant access, configuration, communication, bypass, recovery, and acceptance evidence	Connects cyber assurance to the safety test without replacing it.
Bypass and acceptance record	Purpose, authority, alarms, compensating measures, expiry, restoration, limitation, acceptance	Prevents temporary degraded states becoming hidden permanent conditions.

The case should be bounded to one safety function or clearly defined group. Enterprise averages and generic zone diagrams cannot establish the condition of a specific claim.

A claim may remain conditionally supported when evidence is incomplete, but the limitation, interim control, owner, and expiry must be visible. Unsupported confidence is more dangerous than an explicit unknown.

Worked Assurance Scenario: Logic Change, Vendor Workstation, and Temporary Bypass

During an outage, a maintenance team uses a vendor engineering workstation to update logic associated with a safety function. The function is placed in a temporary bypass while work and proof testing occur. The system is logically separated, but the workstation also supports the basic process control system and uses a shared time and identity service.

The assurance case states the claim that the safety function will return to an authorized, independent, and tested state before operation resumes. The dependency case identifies the shared workstation, identity, time, repository, and vendor procedure. The change pack records the authorized logic source, named personnel, session, comparison, rollback copy, and final baseline.

Proof testing confirms the safety objective, while the cyber evidence confirms the source, change, configuration, and restoration chain. The bypass record shows authorization, alarms, compensating measures, expiry, and closure. One unresolved limitation remains: the shared workstation dependency. The owner accepts it temporarily with a funded separation action and revalidation date.

Assurance question	Evidence	Unacceptable shortcut
Was the intended safety logic used?	Authoritative source, version, integrity, comparison, approval	A local file with no verified provenance.
Was the change attributable and bounded?	Named identity, approved workstation, session, scope, window	Shared account or unrecorded vendor activity.
Was the safety function restored?	Proof-test result, bypass closure, alarms, final configuration, owner acceptance	Closing the work order without restoration evidence.
Does independence remain credible?	Dependency analysis, shared-service controls, limitations, accepted action	Assuming network separation proves complete independence.

The assurance case does not declare the SIS “secure.” It shows why the defined claim is supported, which limitations remain, and who accepted them.

Cyber-Safety Assurance Checklist

Is the safety-related claim specific and owned by the appropriate authority?
Are operating assumptions and demand mode explicit?
Does the argument explain why the evidence supports the claim?
Are shared engineering, identity, time, power, vendor, network, and procedural dependencies visible?
Is the authoritative logic and configuration source known and compared?
Are safety-related changes attributable, tested, and recoverable?
Does proof-test evidence include relevant cyber context without changing the safety objective?
Are bypasses and forced states authorized, alarmed, time-bound, and restored?
Are counter-evidence and limitations retained?
Has the authorized owner accepted the remaining condition and next validation date?

A strong assurance case can state “not yet supported” when the evidence is insufficient. That is a more defensible outcome than a generic positive rating.

90-Day SIS Cyber Assurance Pilot

Days 1–30: Define one claim and dependency boundary

Select one safety function, confirm the safety owner, document assumptions, identify shared dependencies, and collect current configuration, access, change, test, bypass, and recovery evidence.

Days 31–60: Build and challenge the case

Map claim, argument, supporting evidence, counter-evidence, and limitations. Review with safety, engineering, operations, cybersecurity, and the supplier where necessary.

Days 61–90: Test, correct, and authorize

Run the relevant change, proof-test, restoration, or dependency exercise. Correct material defects, record accepted limitations, and schedule revalidation.

Cyber-Safety Assurance Mistakes

Equating segmentation with independence

Shared tools, identity, time, power, repositories, procedures, and personnel can preserve dependency across network boundaries.

Replacing safety evidence with cybersecurity evidence

Cyber controls support confidence in the lifecycle; they do not replace hazard analysis, safety validation, or proof testing.

Ignoring temporary states

Bypasses, forced values, emergency access, and temporary workstations can create the most consequential assurance gaps.

Removing counter-evidence from the final case

A case that cannot be challenged is a justification exercise, not assurance.

Conclusion

Safety systems need a cyber assurance case because trust depends on more than a checklist or zone boundary. The organization must show how access, dependencies, configuration, change, proof testing, bypass, recovery, and acceptance support a defined safety claim.

The strongest case is not the one that claims certainty. It is the one that makes reasoning, evidence, counter-evidence, limitations, and authority visible.

Cyber-Safety Assurance Case Review

CyberTech Intelligence can facilitate a bounded review for one safety function or change scenario and build the first claim, dependency, and evidence case.