Sequenced OT Resilience: A Framework for Consequence-Derived Investment
This paper specifies the Sequenced OT Resilience (SOR) Framework, an investment and execution model for OT resilience in brownfield industrial environments where change capacity is constrained and consequence varies across zones. The argument for why OT environments require a different investment logic from the one most programs currently use is developed in the companion paper, The Coverage Trap. This document specifies the framework that argument points toward. The SOR Framework is a correction to the investment model, not a replacement for the work already done under existing programs.
The companion paper closes by establishing four properties a consequence-derived investment model requires: condition verification rather than control presence, pathway derivation rather than catalog coverage, a stopping point derived from consequence, and explicit ownership of accepted exposure. The SOR Framework operationalises each. Condition verification is enforced through Operating Rule 3: constraints are observed at the operational system, not asserted in documentation. Pathway derivation is enforced through the contact boundary assessment: every control is present because a specific pathway requires it, and every absence is a documented finding. The stopping point is provided by the consequence ceiling and the stage completion criterion. Explicit ownership of accepted exposure is enforced through the governed exposure mechanics: an acceptance is valid only when the named owner can relate the exposure to its operational consequence.
Where coverage execution operationalises an unbounded assume-breach posture, the SOR Framework operationalises the inverse: a bounded exposure posture. Compromise reach is constrained by verified architectural conditions, not assumed unbounded across the estate. Investment is sized to what specific pathways require, not to what universal exposure demands. The bounded posture is what makes a defensible stopping point possible. The unbounded posture is what makes one structurally impossible. These barriers are not individual controls but constraints on the progression from exposure to consequence. The framework does not reason from adversary capability or likelihood. It reasons from system structure: what can reach a function, what it can modify, and what consequence that produces under verified conditions.
The SOR Framework structures how investment is directed, validated, and brought to a defensible stopping point. It is not a compliance framework, a control catalog, a maturity model, or a probabilistic risk model. Controls are derived from the pathways that must be constrained to prevent intolerable consequence, not from catalog coverage or cross-site maturity comparison. Unlike coverage-based programs, which define what must be done but not when enough has been done, the SOR Framework has a defined completion state: when all stages within assessed scope reach Governed status, the remaining work is explicitly below the completed work in the consequence order and the governed exposure position is defensible.
Operationally, a governed site looks different from a coverage-compliant site in three specific ways. First, the security program has a defined completion state: not a maturity score that increases indefinitely, but a position at which the highest-consequence exposures are governed and the remaining work is explicitly below them in the consequence order. Second, the site can describe its worst credible consequence and identify the architectural conditions that prevent it: not a list of controls deployed, but a verified account of what cannot happen. Third, every connection crossing into the operational environment has a named purpose, a documented mechanism, and an accountable owner who can state what happens operationally if that connection is exploited. A coverage-compliant site produces audit artifacts. A governed site produces decisions about consequence with named ownership and a defensible stopping point.
SOR Framework: Practitioner Reference and Illustrative Assessment shows what those decisions look like against a composite high-hazard continuous process site.
1. An OT-native model
Three structural properties of OT environments make the bounded exposure posture operationally feasible. Each is a condition IT environments do not reliably offer and that most OT security programs have not built on.
Consequence varies significantly by zone. A loss of control in a safety-instrumented process and a loss of visibility in an operational support system are not the same category of event. An investment model that applies controls uniformly across that consequence spectrum distributes protection without regard to where it matters most. The SOR Framework derives investment priority from consequence, which means the sequence of work and the stopping point are both determined by the site’s actual consequence profile rather than a universal catalog.
OT architecture supports genuine boundary governance. OT communication patterns are deterministic. Asset populations are relatively static. Legitimate traffic is predictable. A governed boundary in this environment does not need to accommodate the continuous churn that makes IT boundary governance difficult to sustain. IT environments require the assume-breach posture because their architecture does not provide a reliable basis for bounding compromise reach. OT environments do not need to inherit that requirement when their architecture can be verified to bound it. OT’s structural properties are not limitations to be worked around. They are the foundation the investment model is designed to build on.
Change capacity is scarce and operationally constrained. Every control deployment introduces a permanent maintenance obligation. In OT environments operating under constrained operational budgets, that obligation is not automatically absorbable. A model that counts deployment as progress without accounting for the maintenance burden it introduces is not calibrated to this constraint. The SOR Framework treats control selection as a pathway-derived decision and counts only what a specific dependency requires, which limits the accumulated burden to what the assessment actually necessitates.
2. Core constructs and operating rules
The SOR Framework operates through four core constructs and three operating rules: the constructs define what is assessed and governed, the operating rules define how.
Consequence ceiling is an architectural condition, not a measurement. It is the verified state in which unacceptable consequence cannot be reached through a single compromise, because the functions capable of producing that consequence are separated by verified independence. Once the ceiling holds, every consequence accessible through any single compromise is bounded at an acceptable level: operational harm that can be quantified, estimated, and governed. The consequences the ceiling excludes cannot be governed as residual exposure. They must be architecturally excluded. The ceiling is what makes the architectural exclusion verifiable and the investment model tractable. Section 8.5 defines how the ceiling is established, verified, and what applies when it does not hold.
Governed exposure is the state the framework requires for every contact point and dependency it identifies: assessed, documented, and consciously accepted at the appropriate level of the organisation. The framework uses three exposure states: acceptable governed, exception-governed, and ungoverned. Section 3 specifies the governance mechanics and the full definition of each state.
Contact boundary is the governed perimeter between a zone and everything outside it. A zone is defined by functional grouping: the systems that together perform a specific operational function. A contact point is a specific path across that boundary, identified by the capability it delivers and the exposure it creates. An out-of-zone dependency is an external system or service the zone depends on but does not control.
Health baseline is the set of infrastructure-level indicators that confirm a zone is operating in the state the assessment described: servers and workstations in expected states, services running, licenses and certificates current, backup jobs completing, restore paths verified. These indicators occupy a layer invisible to both the process monitoring layer and the network layer. The health baseline makes condition drift visible before it affects operational margin. Each indicator is specified to four fields: specific identity rather than category, current value at point of assessment, defined threshold triggering revalidation, and named owner. The current value field is what makes the indicator falsifiable at the time of assessment.
Operating Rule 1: Dependency-based sequencing. The framework sequences assessment and governance across two dimensions.
Across stages, zones are addressed in consequence-priority order. The stage sequence is derived from which zones carry the highest consequence and which stages are structural prerequisites for those that follow.
Within each zone, the sequence is fixed. Zone-level structural conditions are established first: identity management, physical access governance at the consequence level of the zone, recovery capability, and health baseline. The contact boundary is then assessed and governed. Targeted controls are derived only from the exposure that remains after structural governance is applied. Controls are the last step within a zone assessment, not the starting point.
In both dimensions, the sequence is determined by dependency and consequence, not by catalog order.
Operating Rule 2: Contact boundary assessment. The assessment inventories every connection and dependency crossing the perimeter. For each, it evaluates the operational capability being delivered against the exposure that delivery creates. The primary instrument for reducing exposure is architectural: the assessment asks whether the required capability could be delivered through a lower-exposure mechanism before considering whether controls can limit the exposure of the current one. Every contact point reaches one of three outcomes: governed at minimum exposure through the most appropriate mechanism, redesigned to a lower-exposure mechanism that delivers the same capability, or removed. Section 4 specifies the assessment methodology in full.
Operating Rule 3: Constraint verification. Verification under the SOR Framework concerns enforced constraints, not control presence. A control may be present and not enforce the constraint it was placed to maintain. Verification establishes whether the constraint holds in the operational state, observed at the system rather than asserted in documentation. Verification is binary: a constraint either holds or it does not. Partial verification is treated as non-verification for the purposes of stage governance. Where no specific pathway requirement produced a control, no specific constraint can be verified against it.
3. Governed exposure mechanics
The governance question for any exposure is not whether it exists. Exposure will always exist in brownfield environments operating under resource constraints. The question is whether each exposure is acceptable at the zone’s consequence level, and whether it is governed.
The framework uses three exposure states. Acceptable governed exposure is residual exposure within the consequence-derived tolerance for the zone: assessed, documented, owned, and subject to defined review conditions. Exception-governed exposure is exposure outside target tolerance that cannot be resolved within the current planning cycle: formally accepted by a named owner at the appropriate level, with operational consequence documented, remediation expectation stated, and review condition defined. Acceptability and governance are separate properties: an exposure can be outside tolerance and still governed through formal exception. An unacceptable exposure does not become technically acceptable because it is signed. It becomes governed under a formal exception. Ungoverned exposure is exposure that has not been assessed, has no named owner, or has not been consciously accepted. The framework’s objective at completion is zero ungoverned exposure within the assessed scope. Before completion, unassessed stages remain explicitly reported as unassessed scope, not silently treated as accepted exposure.
A governance artifact documents a posture at a point in time. That posture is valid only as long as the zone described in the record remains consistent with the recorded posture. A governance record remains valid only if changes to the zone’s contact points or dependencies are reassessed against the same logic that produced the record. Without reassessment, documented posture diverges from actual posture.
The same principle applies to architectural diagrams. A documented architecture and an operational reality can diverge without any deliberate change: a boundary that appears on a diagram may not enforce decoupling in practice, a connection shown as terminating in a boundary zone may reach through to OT assets in real time, and a credential store shown as isolated may share infrastructure with adjacent zones. The assessment must verify operating state, not architectural intent.
Governance requires operational consequence language, not technical control language. Engineers perform the assessment, establish the technical truth, and maintain it through change. Management owns the exposure, accepts or rejects based on operational consequence, and does not validate technical correctness. The governance artifact is the bridge between them. Sign-off represents ownership only when the governance record demonstrates that the named owner can relate the exposure to its operational consequence and the conditions under which it becomes realised. Technical assessment records carry the pathway-level detail. Governance artifacts carry the operational consequence description. Both are required. Only the latter constitutes genuine management ownership within this framework.
4. Two assessment layers
Every stage assessment operates through two layers. The zone-level layer establishes the structural conditions the zone must satisfy. The contact boundary layer governs every path through which influence can reach the zone from outside it. Constraint verification under Operating Rule 3 applies to findings from both.
Zone-level structural conditions are assessed as zone-profile properties: each condition either holds for the zone as a whole or it does not. The items and the sequence in which they are established are specified in Operating Rule 1. What constitutes an adequate condition is determined by the consequence level of the zone, not by a universal standard.
Contact boundary assessment covers every connection and dependency through which influence can reach the zone from outside it. For each contact point, the assessment works through three questions.
The first is mechanism selection. A single operational capability is almost always achievable through multiple architectural mechanisms whose governed exposure profiles differ significantly. The assessment establishes whether the current mechanism is the lowest-exposure architectural option for delivering the required capability. Where a lower-exposure alternative exists and has not been used, the mechanism is the primary finding. Architectural redesign is assessed before control-based limitation is considered. Section 8.2 specifies the capability-mechanism pattern in full.
The second is exposure limitation. Where the architectural mechanism is established as appropriate or fixed by operational necessity, the assessment evaluates whether controls can reduce residual exposure to within the consequence-derived tolerance for the zone. Controls applied to limit exposure on a necessary mechanism are a valid outcome. Controls compensating for a mechanism that should have been redesigned are not.
The third is justification. Where the lowest achievable exposure for the required mechanism has been established, the assessment evaluates whether that residual exposure is justified by the operational benefit of the capability. A connection delivering marginal or replaceable function is in scope for removal regardless of its exposure level. High modification capability or wide network reach requires clear and documented justification at the consequence level of the zone.
Mechanism and control are the only two instruments the framework uses to reduce exposure. Everything that remains after both have been applied is governed exposure.
The distinction between the two layers is deliberate. The framework does not govern what an authorised user does through a governed mechanism. It governs the mechanism and the zone conditions that determine what mechanisms are required. Identity management, credential scope, privilege structure, and physical access controls inside a zone are zone-level structural conditions, not boundary governance questions. That is a design boundary, not a coverage gap.
5. Investment logic and stopping point
Security investment at most OT operators competes within a fixed operational budget. This is not a temporary constraint. It is the structural condition any investment model applied to these environments must be designed for.
The SOR Framework uses reachable attack surface as the primary investment target: the total set of pathways through which an adversary or decay process can reach a consequential function. Exposure describes the residual consequence-bearing position after those paths and dependencies are assessed and governed. Probability-based risk quantification requires reliable frequency estimates for OT threat scenarios. Those estimates rarely exist in a form defensible enough to drive prioritisation across heterogeneous OT sites. The framework sequences by consequence and dependency, not by speculative frequency estimates. Threat intelligence informs the credible reachable threat population, tests assumptions behind the consequence ceiling, and can raise the required posture for a contact point even where it does not support a defensible frequency estimate. The absence of defensible probability estimates does not prevent disciplined decision-making. It prevents false precision.
The funnel property. The stage sequence instantiates a specific three-step architectural logic. First, consequence is bounded: Stage 1 establishes the ceiling that defines what is architecturally excluded from the problem the remaining stages need to solve. Second, the primary entry point for adversarial disruption is governed: Stage 2 addresses the IT/OT boundary, the structural path through which IT-origin threats reach operational environments. Once the boundary is governed, the threat population that reaches the interior is materially reduced. Third, the remaining assessment follows consequence order within the bounded space: control zones before visibility infrastructure, visibility before support infrastructure. Each step narrows the problem the next step addresses. Fixed investment applied in this order produces more structural risk reduction than the same investment applied without sequence, because earlier stages directly reduce what later stages need to deliver.
The stopping point. When all stages within the assessed scope reach Governed status, the organisation holds a governed exposure position across the full consequence order. Coverage logic has no equivalent completion state: the catalog defines what must be done, not when enough has been done.
Where resource constraints prevent full completion, the sequence preserves a governed position at the highest-consequence end of the work. Stages that have reached Governed status are fully assessed and governed. Stages that are incomplete are named and sequenced. The unresolved work sits below the completed work in the consequence order, and that position is explicit rather than invisible. The framework does not require full completion to produce a defensible result. It requires that what is complete is genuinely governed and what remains is honestly reported.
6. Two threats, one sequence
The framework is designed to interrupt two categories of threat simultaneously.
The first is operational decay. OT environments accumulate successive generations of control systems and platforms, each generation more dependent on external services than the last. Where earlier systems operated on simple, stable architectures with perpetual licensing and minimal connectivity requirements, newer systems assume license servers, update infrastructure, certificate authorities, and vendor connectivity that the OT environment may not consistently provide. Those dependencies themselves decay: licenses expire, support windows close, certificates lapse, and vendor-maintained components reach end of life while the operational systems that depend on them continue running. The result is progressive divergence between the system’s assumed state and its actual state, accumulating without producing a signal that the divergence is occurring.
The second is adversarial intrusion through ungoverned contact points. External threats reach OT environments through boundaries that have not been brought under technical governance: the network connection to the IT estate, the vendor laptop connected directly to a control system, the engineering workstation with access to both the process network and the internet, the misconfigured firewall rule that leaves a boundary device exposed. Actor intent varies. The structural entry condition does not.
The zone and contact boundary assessment addresses both categories within the same sequence. Boundary governance reduces adversarial reach. It also reduces the cross-boundary dependencies and management-plane relationships that the decay mechanism operates through: fewer connections means a smaller population of systems subject to the dependency patterns that produce decay. Zone-level health baseline verification surfaces the correspondence failures that decay produces before they affect operational margin. Verified recovery limits destructive impact regardless of whether the cause is adversarial or structural.
The structural sequence governs the entry conditions for adversarial disruption and surfaces the foundation conditions for operational decay within the same assessment. Both threat categories become consequential through the same governable structures. The sequence interrupts both because it addresses those structures directly.
7. IT security as OT protection
The IT security layer upstream of the OT environment determines what threat population arrives at the boundary the framework is designed to govern.
The correct architectural relationship between IT and OT security is layered, not parallel. The IT security layer addresses the threat before it reaches the OT boundary. The OT boundary governs what crosses. The OT environment behind that boundary is kept structurally simple: few external dependencies, deterministic communication, governed contact points. That simplicity is not a security weakness. It is the property that makes the OT environment governable and the boundary meaningful.
The framework treats two conditions as mechanisms to be removed rather than risks to be monitored. The first is general-purpose outbound internet access from process zones: where the destination population is arbitrary and traffic is non-deterministic, the mechanism cannot be governed through controls and is incompatible with the structural simplicity the framework depends on. The second is inbound connectivity arriving directly from the internet without traversing the IT security layer: this bypasses the upstream barrier the framework’s stage sequence assumes is in place. A specific, governed outbound connection to a defined cloud endpoint is assessed as a contact point under the same logic as any other crossing. It may be justified. The two conditions above are not assessable in the same way because their exposure cannot be bounded to a specific consequence profile.
Backup orchestration platforms, endpoint detection agents deployed across the full estate, centralised patch management infrastructure, and remote monitoring tools are legitimate operational capabilities. Each also requires inbound network paths, high-privilege credentials, and persistent agent processes that cross zone boundaries by design. When imported without consequence-derived assessment, tools built to protect a dynamic IT environment can defeat the structural simplicity an OT environment depends on. The test is not whether a tool is an IT tool or an OT tool. The test is whether the mechanism introduces privileged cross-boundary access, shared credentials, persistent agents, or management-plane dependency that changes the governed exposure position.
The stage sequence assumes a functioning IT security layer. Where that assumption does not hold, IT security becomes a priority parallel investment that directly changes the Stage 2 boundary posture required. Where the IT security layer is functioning, the threat population arriving at the IT/OT boundary is filtered: opportunistic intrusion is largely blocked before it reaches OT, and the residual population is more targeted and less voluminous. Where IT security is weak or absent, the full unfiltered threat population from the IT estate arrives at the boundary. Stage 2 in that condition requires stronger isolation, fewer crossing points, more constrained mechanisms, and potentially the elimination of contact points that would be acceptable under a mature IT security layer. The IT security maturity assessment is therefore a Stage 2 input, not a parallel workstream. Treating it as a separate program produces a Stage 2 posture calibrated to the wrong threat population.
8. Dimensioning controls to consequence
8.1 The barrier dimensioning logic
Process safety engineering identifies credible paths to intolerable consequences, places barriers proportionate to consequence severity across those paths, and stops where an additional barrier no longer changes the governed exposure position enough to justify its cost, disruption, and lifecycle burden. That logic is the correct discipline for consequence-proportionate investment in OT security.
A governed boundary does not catch a lateral movement path and close it. When its enforced conditions hold, it makes the path structurally unavailable. That distinction is the difference between a control that depends on correct operation and a control that depends on correct architecture. The former degrades directly with operational drift. The latter is less dependent on continuous correct operation, provided the architecture remains governed.
8.2 The capability-mechanism pattern
A single operational capability is almost always achievable through multiple control mechanisms whose governed exposure profiles differ by orders of magnitude. The barrier dimensioning question is not whether to deliver the capability. It is which mechanism delivers it at the lowest residual exposure consistent with the consequence profile, and whether that lowest residual exposure is justified by the operational benefit at all.
The mechanism scale runs from full automation at one end through intermediate mechanisms with progressively reduced privilege or connectivity, through manual operation, to elimination of the capability at the floor. Elimination is a routine output of the assessment, not an exceptional finding.
Three examples illustrate the pattern.
Server health visibility. Full out-of-band hardware management access provides hardware-level control including power cycling, firmware delivery, and BIOS modification over the network. Read-only status polling provides the same health information without inbound write access. Unidirectional device-initiated alerting removes the inbound channel entirely. Manual scheduled inspection removes the network path. The mechanism selected is a documented assessment output at the consequence level of the zone.
Identity verification. Bilateral trust relationships expand the credential footprint linearly with integration count. Federated identity assertion concentrates credential management at a single provider. Manual verification at the point of access removes the network-mediated trust relationship entirely. The mechanism selection is a documented assessment output at each integration point, not a policy applied uniformly across the zone.
Backup management. Centralised push-based backup infrastructure requires inbound credentials and network paths to each protected system. Pull-based backup reverses the trust direction. Manual offline backup removes the persistent network path. Where a centralised backup infrastructure serves multiple independent zones, the cross-zone exposure created by their shared trust relationship must be assessed: the backup system is a contact point for every zone it reaches, not only the zone it was deployed to support.
8.3 Proportionality across the consequence spectrum
The barrier dimensioning logic produces outputs proportionate to the consequence profile. At the high-consequence end, where functional independence between control and safety functions is the consequence ceiling, the assessment produces stringent isolation requirements and a low threshold for eliminating high-privilege inbound connections. At the lower-consequence end, the same assessment logic produces documented and governed dependencies with named owners and defined review conditions. Both are correct outputs of the same framework applied to different consequence profiles.
Consider a vendor remote access path used for diagnostic support. At the safety-instrumented zone, the assessment produces a strong presumption against acceptance. At the process control zone, the same path may be governed at a constrained mechanism: time-bounded access, witnessed sessions, session recording. At the visibility infrastructure zone, the path may be governed with looser constraints: persistent access at reduced privilege, with documented review conditions. At the operational support zone, the same path may be accepted with minimal constraints if the consequence of compromise is bounded to operational inconvenience.
Four zones. Same framework. Four different outputs. None of them are deviations. The framework’s posture is not minimalist. It is governed.
8.4 The consequence ceiling
The ceiling is established by confirming that the path to unacceptable consequence requires defeating more than one independent system. The form of the barrier does not define the ceiling. The verified independence of the barriers does. The ceiling is an architectural condition. It holds or it does not.
Independence means no dependency exists through which a compromise of one domain can reach, modify, or influence the state of the independent protection function. Every dependency crossing the independence boundary is assessed against that criterion. A dependency that permits modification, administrative control, credential reuse, recovery compromise, management-plane influence, or operational state influence invalidates the independence it crosses. Observation-only data paths may be governed where verification confirms they carry no path back to modification or administrative influence over the protected function.
The ceiling holds where the assessment confirms that all dependencies crossing the independence boundary have been assessed and none provides a path through which one compromised domain can influence the other. Where any such dependency exists and has not been eliminated or independently governed, the ceiling does not hold at that boundary. Stage 1 is not complete until every dependency has been assessed against this criterion.
The framework operates at two levels of consequence bounding. The ceiling established in Stage 1 is the process-level bound: the maximum consequence reachable through any single compromise of the control architecture. Within that bound, the capability-mechanism pattern establishes a second level of bounding at zone and contact point level: what an adversary with access to a specific zone or contact point can actually do, constrained by the architecture around it. Both levels are required. The process-level ceiling defines what is architecturally excluded. The zone-level bounding defines what is reachable within what remains, and therefore what each contact point and dependency contributes to the governed exposure position.
In safety-defined environments, the ceiling is formally constituted. The safety case defines which functions are independent and which certified protection layers bound unacceptable consequence. The independence is engineered by design, documented in the safety case, and verified through functional safety regulation. Stage 1 confirms that the current architecture remains consistent with those assumptions: that the systems the safety case treats as independent have not acquired cyber-relevant dependencies since the case was established, and that no integration decision made after the original engineering has invalidated the independence the case relies on. The safety case does not need to have been written with cyber threats in mind. It needs to correctly describe the independence the ceiling depends on. Where it does not, that is a process safety deficit that predates the security engagement. Stage 1 verifies cyber-relevant independence. It does not redesign the safety architecture.
In non-safety-defined environments, the worst credible consequence is still knowable from the physical process: the engineering basis of any industrial site defines what happens under loss of containment, loss of control, or failure of critical handling. The ceiling exists. What is absent is a formal safety case that certifies the architectural conditions enforcing it. Stage 1 derives the ceiling by working from the physical consequence backward: identifying what would need to fail simultaneously for the worst outcome to be reached, and assessing whether those failure conditions are independent of control system state. Where a physical or architectural constraint prevents control system compromise from alone producing the worst consequence, that constraint is the ceiling mechanism. Where no such constraint exists and control system compromise could alone produce the worst outcome, the ceiling does not hold and the environment is in the condition described below.
The credible reachable threat population does not define the ceiling, but it tests whether the assumptions supporting it remain defensible. Where threat intelligence or demonstrated adversary capability shows that an assumed independence barrier can be defeated in ways the original assessment did not consider, the ceiling assessment must be revisited and acceptance thresholds reviewed. The ceiling is a verified architectural condition, not a permanent state. It requires revalidation when the architecture changes and when the threat context provides evidence that the independence assumptions no longer hold.
Where the ceiling does not hold, whether in a safety-defined or non-safety-defined environment, the framework can still surface and govern exposures, but all stage assessments operate as exposure management rather than consequence-bounded investment until the condition is resolved. The response is a process safety or engineering remediation, not a security control. That remediation outranks the security engagement and is outside the framework’s scope to direct.
8.5 Reactive activities
Patching, firmware updates, and reactive configuration hardening share a structural property: the backlog grows faster than the activity can close it, because the rate of vulnerability discovery consistently exceeds the rate of remediation. The structural stages deliver risk reduction independent of the discovery rate. A governed boundary’s protective value is not directly coupled to vulnerability discovery, provided the boundary remains governed and verified. The framework treats reactive activities as parallel backlog unless a specific pathway finding makes them necessary to close a governed exposure within a stage.
9. The stage sequence
The stage sequence below is consequence-derived. It applies wherever consequence varies by zone and where adversarial and decay-based threats become consequential through governable structures. The consequence profile of the environment determines what each stage assessment produces and how stringent the outputs are, not whether the sequence applies.
With the ceiling verified or provisionally bounded through a documented assessment, the framework sequences the work below it. Whether a function warrants independent zone-level treatment is itself a finding from Stage 1: a function whose worst credible consequence is a stopped production line is still a consequence ceiling, and that ceiling bounds all subsequent investment in the same way as a formally defined safety case. The difference is in the stringency of the outputs, not in the structure of the work.
SOR Framework: Practitioner Reference and Illustrative Assessment applies this sequence to a composite high-hazard continuous process site through Stage 1 and Stage 2.
9.1 Scope definition
Zone scoping. A zone is the set of systems that together perform a specific operational function. The zone is defined by the function, not by what reaches it. Everything outside the function is outside the zone, regardless of how closely it interacts with it. A time synchronisation server, an identity provider, or a backup infrastructure system that a zone depends on is not part of that zone. It is an external system with a connection into the zone that must be assessed. A shared infrastructure service that serves multiple independent zones creates connections between those zones through their shared trust relationship. The assessment must evaluate each shared service as a contact point for every zone it reaches.
No two sites produce the same zone map. Defining zones is the first step of the assessment and requires site-specific judgment that cannot be substituted by a standard template.
Uncertainty about what exists is itself a pathway finding. If a site cannot establish what assets are present, what communicates with what, or where credentials are used, the inventory and discovery work required to answer those questions is not catalog hygiene. It is a prerequisite for completing the dependency assessment.
Pre-existing controls. Controls already in place before the assessment are not automatically justified by their existence, and are not automatically removed because the framework would not have selected them as new investment. They remain in scope as contact points, dependencies, trust relationships, and exposure-shaping mechanisms that the assessment must evaluate. If a pre-existing control creates a pathway, shared dependency, or maintenance burden that exceeds its assessed protection value, the assessment may recommend redesign, constraint, or removal.
Controls derivation. Controls are pathway-derived. Every control that appears in the stage output is present because a specific dependency or contact point requires it. Within the assessed scope, every absent control is absent because no assessed path requires it, and that determination is a documented finding.
9.2 How stages work
Governance state. Stages are Governed or Incomplete. Governance works as a gate: a stage does not close until every zone within it passes. A Governed stage may carry the qualifier “with Exceptions” where exception-governed exposures remain: those exposures must appear explicitly in the governance record. Concurrent work across stages is permitted. Reporting is gated by sequence governance status independently of engineering completion. A stage whose engineering work is complete but whose prerequisites are not yet Governed cannot be reported as Governed. Engineering progress and reporting permission follow different rules: progress is not reportable as governed posture until the stages that determine its consequence meaning are themselves Governed.
The within-zone sequence follows Operating Rule 1 (Section 2). Health baseline enumeration runs as a thread through the full zone assessment, producing the indicators that make verified structural state visible over time. The assessment also establishes what the zone depends on and what depends on it, so that the operational consequences of isolation or degraded operation are known before a response decision is required.
Governed criteria template. A stage is Governed when, for every zone or boundary within its scope:
- identity management and physical access governance are verified at the consequence level of the zone
- recovery capability is verified
- health baseline indicators are named, owned, assigned a review mechanism, and meet the four-field standard (specific identity, current value at point of assessment, defined threshold, named owner)
- every contact point is identified and governed
- all out-of-zone dependencies are documented with understood severance implications and named owners
- any exposure outside target tolerance is carried as exception-governed exposure with named ownership, operational consequence, review condition, and remediation expectation
Each stage description below states only the additions or qualifications specific to that stage. All elements of the template apply unless a stage explicitly overrides one.
Maintaining Governed status through change. A Governed zone remains Governed only while it stays in the state the assessment described. Changes to a zone’s contact points, out-of-zone dependencies, zone-level structural conditions, or the architectural assumptions on which the assessment rested require reassessment against the same logic that produced the original record. The change is either confirmed as consistent with the existing posture or governed under a revised posture. Where that reassessment occurs at the time of change, Governed status is continuous. Where it does not, the governance record no longer describes the zone’s actual state. Site change management for any Governed zone therefore requires a reassessment step.
9.3 Stage 1: Consequence structure
Stage 1 is first not because it is the most likely adversarial entry path but because it establishes the consequence ceiling that determines what every later exposure means. Its function is to identify the specific zones whose compromise, individually or in combination, could reach unacceptable consequence, and to govern the independence criteria that prevent a single attack from reaching all of them simultaneously. Once those zones are governed and their independence verified, Stage 1 is Governed and the work below the ceiling can proceed.
Stage 2 is the first primary adversarial barrier. Stage 1 establishes what is at stake if that barrier or any later barrier fails.
The framework does not replace safety engineering. Where a safety model exists, Stage 1 challenges its cyber-relevant assumptions. Where no model exists, Stage 1 constructs the minimum consequence structure needed to identify which zones require independent treatment and what independence criteria apply between them.
The framework treats two genuinely independent barriers as sufficient to bound consequence. The basis for that position is adversarial effort, not layer counting. Compromising a single system requires an attacker to traverse a specific access path: to identify a target, establish a foothold, escalate privilege, and reach the assets that matter. Two genuinely independent systems require two entirely separate sequences of that kind, with no shared credentials, no shared network infrastructure, and no shared administrative access between them. Neither compromise informs or enables the other. An attacker who has fully compromised the control system has gained nothing toward compromising the safety system if the independence is real. The two operations are decoupled by architecture, not by policy.
That decoupling is what makes simultaneous defeat by a single adversarial action architecturally excluded rather than merely unlikely. The difficulty of executing two independent, fully decoupled compromise sequences within a timeframe that matters operationally is not twice the difficulty of one. It is categorically higher, because the attacker cannot leverage the access, knowledge, or credentials from one domain to reduce the work required in the other. Where a third independent barrier exists, the marginal reduction in the probability of simultaneous defeat becomes very small against the engineering cost of maintaining genuine independence for that additional layer. The standard for Stage 1 is therefore two genuinely independent barriers with no shared elements through which a single compromise could defeat both simultaneously.
In practice, the distribution of Stage 1 conditions follows a predictable pattern. Most environments where consequence is high enough to warrant independent treatment already have functional safety systems: the SIS, the certified protection layer, the mechanical interlock. Stage 1 in those environments is primarily a cyber independence verification, not a safety architecture assessment. The safety architecture exists. The question is whether it has remained independent in the cyber-relevant sense. Most Stage 1 findings in safety-defined environments are of this type: functional independence present, cyber independence degraded or unverified. Environments where the worst credible consequence is within acceptable bounds require verification of that bound but rarely produce significant Stage 1 findings. Environments where unacceptable consequence is reachable and no independent mitigating function exists are the least common condition, and the one that produces the most significant Stage 1 output.
Mode A: Safety-defined environments. The consequence-bearing zones are formally defined by the safety case. The SIS is the zone whose independence from the control system is the primary ceiling criterion. Stage 1 verifies that the current architecture preserves the independence the safety case assumes: that the control system cannot defeat the safety functions, that interfaces between control and safety domains are governed, and that no subsequent integration, shared infrastructure, or architectural drift has invalidated that independence.
Hard independence failures are structural: shared credentials, shared workstations, shared network segments between the control and safety domains. These are safety case validity questions, not security risk acceptance decisions. The most common form of this finding is not an absent safety system but a safety system whose cyber-relevant independence has been eroded by integration decisions made after the original engineering: a shared historian connection, a common authentication infrastructure, a management network that reaches both domains. The remediation is to restore cyber independence, not to redesign the safety architecture.
Where the assessment surfaces a hard independence failure, the finding outranks the security engagement. Stage 1 cannot reach Governed until the independence is restored or a formal process safety assessment confirms it is maintained through other means. Security work may continue at lower stages, but those stages cannot be reported as consequence-bounded Governed until the independence deficit is resolved.
Data dependencies through constrained and governed connections are assessable. These are treated as contact points in scope for the Stage 1 assessment, evaluated against the specific consequence of the dependency, and governed or accepted accordingly.
Stage 1 is Governed in Mode A when, in addition to the template criteria: the consequence-bearing zones are identified and the cyber-relevant independence between them is verified against current architecture with no shared elements between domains.
Mode B: Non-safety-defined environments. There is no formal safety case and no certified independent protection layer. Stage 1 begins by establishing whether the worst credible consequence of control system compromise is within acceptable bounds. The worst credible consequence is knowable from the physical process: the engineering basis of the site defines what happens under loss of control, loss of containment, or failure of critical functions.
Where the worst credible consequence is within acceptable bounds, Stage 1 documents and verifies the architectural conditions that enforce that bound. The ceiling holds by the nature of the process. Stage 1 records it, verifies it holds under current architecture, and assigns ownership of the assumptions behind it.
Where the worst credible consequence is not within acceptable bounds, Stage 1 identifies whether any independent mitigating function already exists: a physical interlock, a mechanical safeguard, a second control system with genuinely separate architecture, or any other function capable of preventing the worst outcome independently of the control system that can produce it. In practice, some form of mitigation usually exists. Stage 1 verifies its cyber-relevant independence from the control system using the same criteria as Mode A: no shared credentials, shared network paths, or shared administrative access between the control system and the independent function.
Where no independent mitigating function exists and the worst consequence is not within acceptable bounds, Stage 1 defines the engineering requirement to create one. The requirement is functional: a mechanism capable of preventing the unacceptable consequence independently of the control system. The form of that mechanism is an engineering design decision outside the framework’s scope. Its existence, independence, and verified condition are within Stage 1’s scope. Stage 1 cannot reach Governed in this condition until the independent function exists and its independence is confirmed. In this condition Stage 1 is not only an assessment. It is the engineering brief for the work that must precede all subsequent stages.
Stage 1 is Governed in Mode B when, in addition to the template criteria: the consequence-bearing zones are identified, the worst credible consequence is established from the physical process, and the architectural conditions enforcing the ceiling are verified against current architecture with no shared elements between domains.
Stage 1 completion has a specific effect on every subsequent investment decision. Before Stage 1 is Governed, the consequence space is open: any exposure anywhere in the estate carries an uncertain worst-case outcome, because the architecture has not established what is reachable under a single compromise. After Stage 1 is Governed, the consequence space is bounded: the ceiling defines what is architecturally excluded, and residual risk across all remaining stages is bounded at an acceptable consequence level rather than open-ended. That conversion is what makes the subsequent investment model tractable. Without it, no investment at lower stages can be correctly calibrated because the consequence ceiling that determines proportionality has not been established.
9.4 Stage 2: The IT/OT boundary
Stage 2 addresses the primary OT-owned barrier against the credible reachable threat population that survives the IT security layer. Stage 2 first establishes whether a boundary exists in any meaningful sense. The IT/OT boundary may be absent, nominal, or functioning. Absent means OT assets are accessible from IT infrastructure without a governing perimeter. Nominal means a network perimeter exists but does not perform a genuine boundary function. Functioning means the boundary enforces governed constraints on what crosses it.
A system performs a genuine boundary function only when its OT-side collection and its IT-side access are operationally decoupled: the OT-side connection operates on its own schedule, IT access reaches only that system’s local state, and no IT-side action triggers a real-time OT-side operation. A system placed at the boundary with a write path back into OT carries high modification capability and must be assessed at the consequence level of what it can reach and modify. That capability requires strong justification and evaluation of lower-exposure architectural alternatives before it is accepted. Direct internet exposure of OT assets is treated as absence of a governed boundary for that contact point, not as a contact point awaiting classification.
Contact points include connections between IT and OT networks, remote access paths used by vendors and engineers, data transfer points for historian replication and business reporting, modem and serial connections to external systems, integration points with ERP and business systems, and cloud connectivity used for remote monitoring, vendor support, or data aggregation. Vendor access paths require particular attention: they are scoped around vendor operating models rather than minimum necessary privilege, managed outside the site’s normal change process, and active only periodically in ways that make them easy to overlook. Each contact point is assessed under the same logic regardless of its commercial origin: what capability does it deliver, what does it expose on the OT side, and is the lowest-exposure mechanism being used to deliver it. Commercial benefit to non-OT functions is a valid justification where the OT-side exposure is understood, owned, and accepted at the appropriate consequence level. A vendor-required path that produces unacceptable exposure is carried as exception-governed exposure under the standard escalation path.
The Stage 2 assessment establishes how OT operations depend on IT connectivity and what can be sustained when those dependencies are severed. An architecture that requires OT shutdown to manage an IT security incident has not achieved a governed boundary; it has produced a boundary whose failure mode is operational loss. That condition is not a Stage 2 completion criterion, but it is a diagnostic for whether the boundary is functioning or merely present.
Stage 2 is Governed when, in addition to the template criteria: IT connectivity dependencies are documented with understood operational implications and named owners, and the boundary population is deterministic (every member is known, governed, and deliberately kept; no contact point exists that was not assessed).
9.5 Stage 3: Operational control zones
Stage 3 addresses the receiving end of what the governed IT/OT boundary permits to cross and what adjacent OT zones introduce as dependencies. Stage 2 governs the boundary itself. Stage 3 governs what governed contact points can reach and influence inside each control zone, and what each zone depends on from other OT zones and shared infrastructure. A vendor remote access path assessed at Stage 2 as a contact point at the IT/OT boundary is assessed again at Stage 3 for each control zone whose assets, credentials, tools, or workflows it can influence. This is not duplicate assessment. It separates boundary governance from zone consequence.
Each zone is assessed individually across the full population of paths through which influence can reach it from outside the zone. That population includes governed contact points arriving through the IT/OT boundary, connections from other OT zones, engineering workstation access originating outside the zone, historian and visibility system connections, and any other out-of-zone dependency. Dependencies from adjacent OT zones require the same assessment logic as IT-origin contact points: what capability does the dependency create inside this zone, through what mechanism, and is that mechanism the lowest-exposure option for delivering the required function.
Dependency mapping establishes what the zone depends on and what it can sustain if those dependencies are severed. Every out-of-zone dependency is identified, assessed, and either governed at the lowest-exposure mechanism the operational requirement permits or carried as documented accepted exposure with named ownership.
Stage 3 is Governed when the template criteria are met for every zone in scope.
9.6 Stage 4: Process operational visibility
Stage 4 addresses the infrastructure providing operators with real-time process awareness: SCADA systems, historians, and alarm management platforms. Visibility systems are classified by influence, not by label. A historian, alarm platform, or SCADA component that can write to control assets, suppress alarms, modify operator decision-critical data, or carry privileged trust into a control zone is assessed at the consequence level of that influence. Each distinct functional grouping constitutes its own zone and is assessed under the same dependency mapping logic as Stage 3.
Stage 4 zones receive influence from Stage 3 control zones through data feeds, process state connections, and alarm sources. These OT-to-OT dependencies are assessed using the same contact boundary logic: what capability does the dependency create inside this zone, through what mechanism, and is the mechanism the lowest-exposure option for the required function. The consequence profile at each Stage 4 zone is assessed from the site architecture rather than assumed to be lower than control zones.
Stage 4 is Governed when the template criteria are met for every zone in scope.
9.7 Stage 5: Operational support infrastructure
Stage 5 governs shared operational support services as zones in their own right: OT networks, identity infrastructure, shared storage, PKI, backup infrastructure, and time synchronisation.
This is distinct from the assessment of shared service dependencies that occurs within earlier stages. When a Stage 2 or Stage 3 assessment encounters a dependency on a shared service, it assesses that dependency for the purpose of that stage and at that stage’s consequence level. Earlier stages can reach Governed without Stage 5 being complete, provided the specific dependency each stage holds on the shared service is assessed and governed at that stage’s consequence level. Stage 5 then assesses the shared service zone itself: its own contact boundary, its internal structural conditions, and its dependencies on other infrastructure.
A shared service that reaches multiple zones is a contact point for every zone it reaches, not only the zone it was originally deployed to support. The cross-zone exposure created by shared trust relationships must be assessed for each dependent zone. Where shared services are required to establish Stage 2 or Stage 3 conditions, those dependencies are assessed as part of the earlier stage.
Stage 5 is Governed when the template criteria are met for each shared service zone in scope.
9.8 Stage 6: Health baseline confirmation and monitoring
Stage 6 is structurally different from the preceding stages. Stages 1 through 5 each govern a zone or boundary. Stage 6 does not. It has no zone of its own and introduces no new assessment logic.
The health baseline indicators defined during Stages 1 through 5 are the instrument by which zone condition changes become visible between full reassessments. A certificate approaching expiry, a backup job that has stopped completing, a restore path that has not been verified: these are the specific signals that a zone’s structural conditions may have changed from the state the assessment described. Where Stage 6 has assigned automated monitoring to those indicators, threshold crossings trigger reassessment of the affected zone. Where monitoring is manual or periodic, the review cycle serves the same function. Stage 6 is what makes governance a continuous property rather than a point-in-time record.
During Stages 1 through 5, every zone assessment enumerates health baseline indicators and records them to the four-field standard. The review mechanism assigned at that point is manual or periodic. Automated monitoring infrastructure is not deployed as part of zone assessment. The governed state of a zone is a prerequisite for assessing whether monitoring infrastructure directed at that zone can itself be governed: a contact point, management dependency, or privileged inbound path introduced before the zone assessment is complete cannot be evaluated against criteria that have not yet been established.
With the zone assessments complete, Stage 6 evaluates which health baseline indicators warrant automated monitoring and whether the infrastructure required to deliver it can be governed as a contact point under the framework. The evaluation applies the same capability-mechanism logic as any other contact point assessment: what capability does the monitoring infrastructure deliver, what does it expose, and is the lowest-exposure mechanism being used. Where the monitoring infrastructure can be governed without introducing dependencies the assessment would otherwise require to be redesigned or removed, automated monitoring is a valid Stage 6 output. Where it cannot, the manual or periodic mechanism assigned during zone assessment is the correct output for that indicator.
Stage 6 is Governed when every health baseline indicator defined in preceding stages has, in addition to the four-field specification confirmed current: a named owner confirmed to have operational authority to investigate and act, a defined review condition specifying frequency or trigger, and a selected review mechanism documented as an assessment output.
Stage 6 completion is completion of the SOR sequence within the assessed scope. Regulatory compliance, corporate security programs, and sector-specific mandates are managed by the site through their own governance processes.
10. Externally mandated activities
Controls absent from the SOR assessment outputs are absent because no assessed pathway required them in that environment. That determination is a documented assessment finding and constitutes the pathway-derived justification for why a control is not present at that site. Most risk-based regulatory frameworks permit site-specific pathway reasoning as justification for control absence: a control mandated in general guidance may be unnecessary where the pathway it addresses does not exist or has already been governed by other means.
Where an external obligation mandates a control the assessment did not identify, the site has two positions: demonstrate through the assessment record why the pathway requiring that control is absent or governed, or implement the control and govern it as a standard contact point or zone-level structural condition under the same assessment logic. Managing that obligation is the site’s responsibility. The assessment record is the evidence base for either position.
11. Applicability and correct instantiation
The stage sequence applies wherever consequence varies by zone and adversarial and decay-based threats become consequential through governable structures. What varies across environments is not the sequencing logic but its instantiation: which systems constitute the consequence ceiling, where the primary barrier sits, and what completion means at each stage. The instantiation in this paper is derived for high-hazard continuous process environments operating under functional safety regulation. Whether the logic transfers correctly to other OT environment types has not been systematically tested. The argument for transferability is structural: consequence-priority sequencing, pathway-derived controls, and governed exposure mechanics are not properties of any specific environment type. But that argument has not been validated across the full range of OT environments, and practitioners applying the framework outside high-hazard continuous process contexts should treat their instantiation as a derivation requiring site-specific judgment, not a direct application of the sequence described here.
11.1 Application conditions
The methodology delivers its highest return in environments where consequence is material, disruption tolerance is low, and the safety and automation boundary is load-bearing to the operational and safety case.
Correct instantiation may produce findings that require architectural change before governance is achievable. A zone whose assets span consequence levels that require different treatment may need to be divided into functionally separate zones. Shared identity infrastructure that violates zone independence criteria may need to be separated. A boundary that exists only nominally may need to be rebuilt from a different architectural basis before it can be governed. These are assessment outputs, not scope exceptions. The framework evaluates whether the current architecture is adequate for governed consequence. Where it is not, the finding is an architectural requirement. Governance of the existing architecture is not the only outcome the assessment can produce.
11.2 What the framework requires and where it fails
The SOR Framework requires more judgment at the assessment layer than coverage logic in its base implementation. That is not a weakness. It is what prevents false assurance. Coverage logic in its minimal form can be specified against a catalog, implemented against control categories, and verified against documented presence. SOR cannot be correctly applied without judgment across process operations, functional safety, and IT infrastructure simultaneously. A framework that produces correct outputs only when correctly applied is more demanding than one that produces plausible-looking outputs regardless. The SOR Framework implemented without adequate judgment produces outputs that are structurally wrong in ways that may be visible at the gross failure level but are harder to detect where the competence gap is partial: a zone boundary drawn slightly wrong, a trust relationship missed because the assessor lacked fluency in the relevant domain. Those failures produce zone boundaries and pathway assessments that can be challenged against the actual architecture, but only by someone with sufficient competence to do the challenging.
The failure modes below define the conditions under which the framework produces artifacts without producing posture.
Scope inflation is the primary structural failure. Zones are defined too broadly, absorbing external systems into the zone rather than assessing them as contact points. The contact point list becomes artificially short. Dependencies that require governance are instead concealed inside the zone boundary. The assessment cannot see what it needs to see.
Acceptance without consequence ownership is the primary governance failure. The named owner signs a technical finding without being able to relate it to operational consequence. The artifact exists. The ownership does not. Acceptance without consequence ownership produces two subordinate failure modes: completion creep, where Stage 1 or Stage 2 governance is treated as the terminal state and the sequence is abandoned after early stages with later exposure implicitly accepted without assessment; and verification substitution, where documented verification replaces observed verification and the constraint is recorded as present without being confirmed to hold.
Governance decay through undocumented change is the primary operational failure. A high-quality initial assessment degrades as changes accumulate outside the reassessment requirement. The mechanism is configuration changes made under time pressure without a formal change record: authorised engineers, not bad actors, making necessary adjustments that never trigger the reassessment the framework requires. The framework does not eliminate this failure mode. It makes the failure visible: a site that cannot sustain reassessment-on-change cannot honestly report Governed status, and that honest reporting is itself a governance output. But visible failure is not prevented failure.
The three failure modes share a common prerequisite condition. The framework is designed to operate inside an environment that already treats control system configuration as governed process-critical change. Where that discipline exists, the reassessment-on-change requirement maps onto structures already in place: the same change governance that prevents undocumented transmitter range changes prevents undocumented changes to governed connections. Where it does not, no security framework produces a durable governed posture, and the inability to report Governed status is itself a finding.
The pattern is consistent: artifacts exist, posture does not.
12. Regulatory position
The SOR Framework occupies the risk management layer that regulation such as NIS2 Article 21 requires. Article 21’s operative requirement is appropriate and proportionate risk management: risks identified, assessed, owned, and governed in the specific operational environment. The SOR assessment outputs, stage sequence, governed exposure records, and consequence-derived acceptance decisions are the evidence that requirement calls for. Controls that do not appear in the output were not identified because no assessed pathway required them in that environment. That determination is itself a proportionality argument under risk-based regulation.
The framework also addresses the governance accountability requirement that NIS2 Article 20 places on management bodies. Article 20 requires that management approves and oversees cybersecurity risk management measures and carries accountability for that oversight. That requirement is not satisfied by a signature on a gap list or a maturity score. It requires that management understands what they are accepting at the level of operational consequence. The SOR Framework’s governance mechanics make that understanding a completion criterion: an exposure acceptance is valid only when the named owner can relate it to its operational consequence. The result is a governance record that demonstrates management understanding, not merely management signature.
Close
The coverage model answers one question well: what controls has the program deployed. It cannot answer whether those controls govern the pathways through which consequence is reached, whether the conditions those controls depend on still hold, or when enough has been done. Those questions remain open regardless of how high the coverage score climbs.
The SOR Framework is built to answer them. Every contact point is assessed and governed or removed. Every exposure is documented and owned at the level of operational consequence. Every stage has a defined completion criterion derived from the consequence profile of the environment. When investment capacity is exhausted, completed stages are governed within assessed scope, unresolved exposure is explicit, and accepted exposure is owned by someone who understands what they are accepting.
That is a different promise from coverage. It is also a more accurate one.
The instantiation in this document has been developed and is being tested within one environment type. It will need revision as application surfaces conditions it did not anticipate. Practitioners who find cases the framework cannot handle correctly are the intended source of that revision. A framework derived from practice should be corrected by practice.