Markdown GitHub

CERG Example: Day in the Life Operational Stories

These examples show how CERG flows, roles, records, and evidence come together during normal operations. They are not new requirements. They are narrative walkthroughs that help a reader see how existing CERG artifacts are used in real work.

If you are a leader or SME new to CERG, read Story 2 or Story 3 first. They show the program producing outcomes under pressure without requiring prior knowledge of every artifact.

If you are adopting CERG Lite (2-8 people), read Story 8 first. It is the only story written for a small team that owns everything.

If you are running CERG Standard or Regulated, any story applies directly. Each one names the primary flow, supporting procedures and standards, the pillar that owns each step, and the records and evidence produced.

How to use these stories

Onboarding. Use them to explain how the three pillars interact without requiring every pillar to own every task.
Tabletop exercises. Run the walkthrough as a scenario. Test whether your local records, evidence stores, and dashboards can support the steps.
Implementation planning. Use them to identify missing integrations between intake, ticketing, GRC, evidence storage, identity, vulnerability, and reporting systems.
Adoption storytelling. Adapt the roles, systems, and timing to your Organization Adaptation Profile without changing the underlying accountability model.

These stories are illustrative, not normative. They may reference documents or stories that are planned for a future V1.x release. Where they do, the link or marker says so.

Inventory note: Stories 1-7 and 11 are embedded below for fast scanning. Stories 8-10 are standalone files because they are longer adoption narratives. This README is the authoritative examples index for the day-in-the-life set.

Stories at a glance

#	Story	Primary flow	Best for
1	New SaaS application	F-02 Project Intake, Architecture Review, and Threat Modeling	Intake and Architecture Review procedure walkthrough
2	Critical vulnerability	F-04 Finding to Remediation, Exception, or Residual Risk	Exposure Management and SLA discipline under pressure
3	Audit request	F-07 Metrics, Oversight, and Improvement Routing	Evidence quality and audit response
4	Major cloud workload launch	F-02 + F-03 + F-05	Architecture, asset registration, and release routing together
5	Privileged access review finds excessive access	F-04 + F-07	Access reviews and recurring-finding program improvement
6	Third-party security incident notification	F-06 + F-04	Vendor incidents and handoff to IR
7	Enterprise AI assistant rollout	F-02	AI standard application and controlled pilot pattern
8	CERG Lite - Maria and the Tuesday scanner report	F-04	Small-team MVC operations and exposure triage
9	F-01 Control Intent - when the regulator changes the rule	F-01	Translating regulatory change into implementation work
10	The new CISO’s first 90 days	MVC + F-07	First-quarter operating rhythm for a new security leader
11	OT maintenance-window patch deferral	F-04	OT/BES patch deferral, CIP routing, and compensating controls

Story 1: New SaaS application

Situation

A business team wants to adopt a customer success SaaS platform. The tool will process customer contact data, integrate with the identity provider, and export activity logs to the enterprise SIEM. The business wants go-live in six weeks.

CERG flow pattern

Primary flow: F-02 Project Intake, Architecture Review, and Threat Modeling

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	The Business Owner submits a project intake for the new SaaS vendor.	Business Owner	Project Intake Record
2	Governance confirms required intake fields, expected go-live date, business owner, data types, and regulatory scope.	Governance Pillar	Intake completeness check
3	Engineering applies the tiering model. Because the service is internet-facing SaaS with identity integration and customer data, it is not routed as a low-risk known pattern.	Engineering Pillar	Architecture Review Record
4	Risk initiates vendor risk assessment and requests security documentation, subprocessors, breach history, data residency, and contract security terms.	Risk Pillar	Vendor assessment file
5	Data classification is confirmed. The project is tagged for customer data handling requirements and retention expectations.	Governance Pillar	Data classification decision
6	Access requirements are defined: SSO required, MFA inherited from the IdP, role-based access, least privilege groups, named admin accounts, and periodic access review scope.	Engineering Pillar	Access design evidence
7	Logging requirements are applied: administrative activity, authentication events, privilege changes, export events, and integration failures must be available for monitoring.	Engineering Pillar	Logging requirement checklist
8	Open risks are dispositioned. A missing vendor feature becomes either a remediation before go-live, a time-bound exception, or a risk acceptance package.	Risk Pillar	Risk Record or Exception Record
9	Evidence is stored with the intake package: review notes, vendor questionnaire, contract clauses, data classification, access design, logging validation, and final disposition.	Evidence Librarian	Evidence index entries
10	Metrics update after closure: intake cycle time, reviews by tier, vendor risk completion, exceptions opened, and pre-go-live issues remediated.	Governance Pillar	Reporting Metric Record

Example day-in-the-life narrative

On Monday morning, the business sponsor opens the intake record and identifies the system owner, target go-live date, expected users, data elements, and vendor contact. Governance reviews the intake the same day and sends one clarification: the initial request says “customer data” but does not identify whether regulated data is included.

By Wednesday, Engineering completes the architecture review. The design uses SSO, two privileged admin groups, SCIM provisioning, and a vendor-hosted API. Engineering confirms that the application cannot go live unless admin activity and user authentication logs are exportable. Risk starts the third-party assessment in parallel instead of waiting for architecture review closure.

The vendor returns a SOC report, penetration test summary, subprocessors list, and data processing addendum. Risk identifies one gap: customer data exports are logged in the vendor console but are not available through the standard log API. The Business Owner agrees that exports will be limited to two approved roles until the vendor API feature is available.

At the go-live decision meeting, Engineering confirms SSO, access groups, and log ingestion for authentication and admin events. Risk documents the export-log limitation as a time-bound exception with compensating controls. Governance verifies that evidence is indexed and that the exception expiration date is on the calendar.

Operational outputs

Project Intake Record closed with security disposition.
Architecture Review Record approved with conditions.
Vendor assessment completed and linked.
Data classification decision recorded.
Access model and logging evidence stored.
Exception Record created if a requirement is deferred.
Metrics updated for intake throughput, cycle time, and exception volume.

Story 2: Critical vulnerability

Situation

A vulnerability scanner reports a critical remote-code-execution exposure on an internet-facing application server. Threat intelligence indicates public exploit code is available. The affected application supports a customer portal.

CERG flow pattern

Primary flow: F-04 Finding to Remediation, Exception, or Residual Risk

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Scanner creates a critical finding for an internet-facing server.	Risk Pillar	Finding Record
2	Risk validates reachability, asset ownership, exploitability, compensating controls, and whether active exploitation indicators exist.	Risk Pillar	Triage notes and severity decision
3	Engineering owns remediation planning and coordinates patching, configuration change, WAF rule, or service isolation.	Engineering Pillar	Change Record
4	Governance checks the applicable SLA, evidence expectations, and whether required records are complete.	Governance Pillar	SLA and evidence review
5	If remediation will miss SLA, the Technical Owner submits an exception request with rationale, compensating controls, and expiration date.	Technical Owner	Exception Record
6	If residual risk is material, the Business Owner and CISO review the risk package and approve, reject, or require further treatment.	Business Owner and CISO	Risk acceptance memo
7	Metrics update for critical findings, SLA performance, exceptions, reopen rate, and time to validate remediation.	Governance Pillar	Reporting Metric Record
8	Lessons learned determine whether standards, baselines, scanning coverage, or patch windows need updates.	Risk Pillar	Improvement Record

Example day-in-the-life narrative

At 8:15 a.m., the scanner imports a critical finding and automatically maps it to the customer portal asset record. Risk confirms the server is internet-facing and that exploit code is available. Because public exploitation is plausible, the finding remains Critical and receives the critical SLA.

By 9:00 a.m., Engineering owns the remediation bridge. The application team reports that the vendor patch requires a minor version upgrade and a brief outage. The Business Owner approves an emergency maintenance window at noon. Engineering also applies a temporary WAF rule while preparing the patch.

Governance does not run the patch. Governance confirms the SLA clock, expected evidence, and required linkage between the Finding Record and Change Record. Risk monitors for indicators of compromise and confirms that no incident declaration is required based on current evidence.

At 12:30 p.m., Engineering completes the emergency change and uploads patch output, service validation, and rollback-not-used confirmation. Risk rescans the asset and validates closure. Governance records that the critical SLA was met and the dashboard updates that evening.

During lessons learned, the team discovers that this application missed a monthly dependency owner review. The action is not just “patch faster.” The program improvement is to update the secure configuration baseline and require explicit owner validation for internet-facing dependencies.

Operational outputs

Finding Record created, triaged, and closed or promoted.
Change Record linked to remediation evidence.
Exception or Risk Record created only if remediation misses SLA or residual risk remains.
CISO or Business Owner acceptance captured when required.
Metrics updated for critical vulnerability operations.
Improvement Record created when the issue reveals a systemic control gap.

Story 3: Audit request

Situation

An external auditor requests evidence that privileged access reviews were performed for a SOX-relevant financial application during the prior quarter. The auditor asks for the review population, reviewer sign-off, exceptions, and evidence that removals were completed.

CERG flow pattern

Primary flow: F-07 Metrics, Oversight, and Improvement Routing

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Auditor requests privileged access review evidence for a defined system and period.	Auditor or Governance Pillar	Audit request ticket
2	Governance pulls the evidence index and maps the request to control, system, period, and required evidence quality tier.	Governance Pillar	Evidence index extract
3	Engineering supplies the IdP export, application role export, reviewer attestation, and removal tickets.	Engineering Pillar	IdP and application evidence
4	Risk explains open exceptions, overdue removals, or residual access risks that existed during the period.	Risk Pillar	Exception or Risk Record summary
5	Governance applies evidence quality rules and checks completeness, timestamp integrity, reviewer authority, population accuracy, and chain of custody.	Governance Pillar	Evidence quality assessment
6	If evidence gaps or control failures are found, they become program work rather than ad hoc audit responses.	Governance Pillar	Finding Record or Improvement Record

Example day-in-the-life narrative

The auditor sends the request on Tuesday afternoon. Governance translates the request into the control language used internally: quarterly privileged access review for the SOX-relevant finance application. The Evidence Librarian locates the prior quarter evidence package and sees that the reviewer attestation is present but the IdP export file name does not include the extraction timestamp.

Engineering regenerates a current export for comparison and supplies the original system-generated export from the access review tool. The application owner confirms that the review population included all privileged groups and all break-glass accounts. Two removals were requested during the review period, and Engineering links the completed removal tickets.

Risk adds context for one exception. A privileged service account could not be removed because a replacement integration was still being tested. The exception had compensating monitoring, a named owner, and an expiration date. Governance includes that explanation in the audit response package instead of letting the auditor infer that the exception was unmanaged.

Governance applies the evidence quality tier and identifies one improvement: export naming was inconsistent across applications. The audit response is completed, but the work does not stop there. Governance creates a program improvement item to standardize evidence naming and extraction metadata for all access reviews.

Evidence request package example

Request Element	CERG Handling	Evidence Included
Control and period	Governance maps the auditor’s wording to the access review control and the prior-quarter review window.	Control mapping, request ticket, period definition
Population completeness	Engineering proves which accounts and privileged groups were in scope at extraction time.	IdP export, application role export, break-glass account list
Reviewer authority	Governance confirms the reviewer was the named system owner or delegated approver.	Reviewer attestation, delegation record if applicable
Exceptions and removals	Risk explains open exceptions; Engineering proves completed removals.	Exception summary, removal tickets, closure timestamps
Evidence quality	Governance checks source, timestamp, immutability, chain of custody, and naming discipline.	Evidence quality checklist, evidence index links
Response package	Governance sends the package with an answer narrative instead of loose screenshots.	Final response memo, linked evidence bundle, improvement item if needed

The auditor receives a coherent evidence package, not a zip file of screenshots. The Business Owner sees whether the control actually ran. CERG gets a reusable improvement when evidence quality is weaker than the control itself.

Operational outputs

Audit request mapped to control, system, period, and evidence requirements.
Evidence package assembled from the evidence index.
IdP, application, attestation, and removal evidence linked.
Exceptions and risks explained with current status.
Evidence quality tier applied.
Findings or improvements created for evidence gaps.

Story 4: Major cloud workload launch

Situation

A product team is moving a customer-facing API from a data center to a cloud platform. The workload will use managed compute, managed database, object storage, secrets management, and centralized logging. The launch is tied to a business commitment, so the team needs clear security gates without creating avoidable delay.

CERG flow pattern

Primary flows: F-02 Project Intake, Architecture Review, and Threat Modeling, F-03 Asset Registration and Coverage Validation, and F-05 Change and Release Security Routing

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Business submits the launch request with go-live date, customer impact, data types, and service owner.	Business Owner	Project Intake Record
2	Engineering reviews the reference architecture, network paths, identity model, encryption, secrets, and deployment pipeline.	Engineering Pillar	Architecture Review Record
3	Risk facilitates threat modeling because the workload is internet-facing and handles customer data.	Risk Pillar	Threat Model Record
4	Governance confirms the applicable cloud, logging, evidence, and change requirements before release approval.	Governance Pillar	Control conformance checklist
5	Engineering registers cloud assets, owners, criticality, data classification, monitoring coverage, and backup expectations.	Engineering Pillar	Asset Records
6	Risk validates residual launch risks, such as incomplete rate limiting or delayed DDoS testing, and determines whether an exception is needed.	Risk Pillar	Risk Record or Exception Record
7	Governance verifies release evidence and updates metrics for architecture reviews, threat models, asset coverage, and launch exceptions.	Governance Pillar	Reporting Metric Record

Example day-in-the-life narrative

The project arrives with a firm go-live date, so Engineering immediately routes it as a regulated internet-facing workload rather than a routine infrastructure change. The first architecture review identifies two issues: object storage needs explicit public-access blocking, and secrets must move from pipeline variables to the managed secrets service.

Risk runs a short threat model with the product team. The highest-priority scenario is credential theft leading to API abuse and data export. Engineering adds rate limiting, privileged workflow logging, and alerting for abnormal export volume. Governance confirms that the evidence package must include asset registration, logging validation, threat model decisions, and the final change approval.

Two days before launch, Engineering proves that logs are flowing to the SIEM and that cloud assets have owners and classifications. Risk validates and recommends the disposition for one low residual risk around delayed DDoS exercise completion with a 30-day due date; the Business Owner accepts the consequence under the RMF authority path. Governance confirms the exception is time-bound and visible in reporting. The release proceeds with clear ownership rather than informal verbal approval.

Operational outputs

Intake, architecture review, threat model, asset, and change records linked.
Cloud assets registered with ownership, classification, and monitoring status.
Logging and alerting evidence captured before go-live.
Residual launch risks recorded with owners and due dates.
Metrics updated for review cycle time, asset coverage, and exceptions.

Story 5: Privileged access review finds excessive access

Situation

A quarterly privileged access review finds that several users retained administrator access after changing roles. One account belongs to a contractor whose engagement ended two weeks earlier. The application supports a sensitive business process.

CERG flow pattern

Primary flows: F-04 Finding to Remediation, Exception, or Residual Risk and F-07 Metrics, Oversight, and Improvement Routing

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Governance identifies excessive privileged access during the scheduled review.	Governance Pillar	Access review evidence
2	Engineering removes access, disables stale accounts, and validates group membership after remediation.	Engineering Pillar	Access removal tickets
3	Risk evaluates whether the access created material exposure, whether activity review is needed, and whether the issue is systemic.	Risk Pillar	Finding Record
4	Governance checks evidence quality, reviewer sign-off, removal timestamps, and whether review SLA was met.	Governance Pillar	Evidence quality assessment
5	If access cannot be removed immediately, the owner requests a time-bound exception with monitoring or compensating controls.	Asset Owner	Exception Record
6	Metrics update for review completion, excessive access rate, removal cycle time, contractor access defects, and recurring findings.	Governance Pillar	Reporting Metric Record
7	Lessons learned feed standards, joiner-mover-leaver controls, contractor offboarding, or role engineering work.	Risk Pillar	Improvement Record

Example day-in-the-life narrative

Governance starts the quarterly review by pulling the privileged group membership and sending it to the approved application owner. The owner flags five users who no longer need administrator access. Engineering removes four immediately but discovers that the contractor account is still active in the IdP.

Risk opens a finding because the contractor access represents exposure after engagement end. Risk asks Engineering to review recent privileged activity and confirms that no suspicious activity is visible. Governance verifies that the reviewer decision, removal ticket, timestamped export, and validation export are all stored in the evidence package.

The team does not treat this as a one-off cleanup. Risk notices the same mover issue appeared in another application last quarter. Governance creates an improvement item to strengthen role-change triggers and contractor offboarding evidence. Engineering agrees to add automated group-owner notification when a privileged user changes department or employment type.

Operational outputs

Access review evidence completed and quality-checked.
Excess access removed and independently validated.
Finding opened for stale privileged access exposure.
Exception created only where immediate removal is not possible.
Metrics and program improvement items updated.

Story 6: Third-party security incident notification

Situation

A vendor notifies the organization that its file transfer platform was compromised. The organization uses the vendor to exchange operational reports with customers. The vendor cannot yet confirm whether customer files were accessed.

CERG flow pattern

Primary flows: F-06 Incident to Recovery to Standards Feedback and F-04 Finding to Remediation, Exception, or Residual Risk

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Vendor notification is received and triaged for affected services, data, dates, and contract obligations.	Risk Pillar / Vendor Risk Analyst	Third-party incident triage record
2	The Incident Commander determines whether to declare an internal incident, assigns severity if needed, and sets the next decision time.	Incident Commander / Standing IR Team	IR-owned Incident Record or documented no-declaration rationale
3	Engineering identifies integrations, disables risky transfer paths if approved by the IC, rotates credentials, and preserves logs.	Engineering Pillar	Containment and log evidence
4	Governance supplies evidence requirements, regulatory mapping support, and decision-log indexing to the IC / Legal process.	Governance Pillar	CERG evidence index and support log
5	Risk coordinates vendor questions, exposure analysis, and residual third-party risk.	Risk Pillar	Vendor Risk Record or Risk Record
6	Engineering implements technical recovery actions, such as credential rotation, endpoint validation, and alternate transfer process.	Engineering Pillar	Change or recovery records
7	Governance tracks CERG support actions, customer or regulator evidence needs, and metrics for third-party incident response.	Governance Pillar	Reporting Metric Record
8	Lessons learned update vendor requirements, contract clauses, monitoring expectations, or exit criteria.	Risk Pillar	Improvement Record

Example day-in-the-life narrative

The vendor notice arrives at 4:30 p.m. Risk opens the triage record and asks three questions immediately: what data types were exchanged, what dates are in scope, and what indicators or logs are available. Because customer operational reports may be involved, Risk notifies the Incident Commander. The IC does not delegate the incident decision to CERG; the IC determines whether this is an internal incident, names the next decision time, and tells CERG what support is needed.

Engineering identifies the integration owner, pauses scheduled transfers after IC approval, rotates API credentials, and preserves local transfer logs. Governance opens the CERG evidence/support log, maps possible notification obligations for Legal and the IC, and records who will approve customer communications if data exposure is confirmed. The CISO receives a short status summary with known facts, unknowns, next decision time, and current containment actions. Risk pushes the vendor for file-level access evidence and maps the scenario to the vendor risk record.

The next morning, the vendor confirms that no organization files were accessed, and the IC documents that no internal incident declaration is required. The vendor still cannot meet the evidence quality the organization normally requires. Risk records residual third-party risk. Governance requires the evidence limitation to be visible in the file, not hidden in email. Engineering implements an alternate encrypted transfer path for the most sensitive reports until the vendor completes remediation.

Operational outputs

Third-party incident triage and IC declaration/no-declaration rationale recorded.
Integrations, credentials, and logs preserved or remediated.
Vendor risk record updated with incident facts and residual risk.
Governance evidence package prepared for executive, customer, regulator, or audit use under IC / Legal direction.
Vendor standards and contract requirements updated if gaps are found.

Story 7: Enterprise AI assistant rollout

Situation

A business function wants to deploy an enterprise AI assistant for summarizing documents, drafting communications, and searching internal knowledge. The tool may process confidential information and has browser, email, or document repository integrations.

CERG flow pattern

Primary flow: F-02 Project Intake, Architecture Review, and Threat Modeling

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Business submits the AI use case, user population, data sources, integrations, and desired productivity outcomes.	Business Owner	Project Intake Record
2	Governance confirms whether the use case is allowed, restricted, or prohibited under the AI standard and data classification rules.	Governance Pillar	AI use-case disposition
3	Engineering reviews identity integration, permissions inheritance, connector scope, logging, retention, and administrative controls.	Engineering Pillar	Architecture Review Record
4	Risk assesses vendor controls, model/data handling, prompt and output risks, sensitive data exposure, and abuse scenarios.	Risk Pillar	Vendor assessment and Threat Model Record
5	Governance defines required user guidance, evidence, monitoring metrics, and approval conditions for pilot or production rollout.	Governance Pillar	Control conformance checklist
6	Engineering implements scoped pilot access, connector restrictions, logging, and administrative guardrails.	Engineering Pillar	Implementation evidence
7	Risk reviews pilot outcomes and open risks before expansion.	Risk Pillar	Risk Record or approval notes
8	Metrics update for AI use cases reviewed, approved, restricted, exceptions, incidents, and user population.	Governance Pillar	Reporting Metric Record

Example day-in-the-life narrative

The business request starts as a simple productivity ask, but the intake reveals that the assistant will index internal documents and email content. Governance checks the AI standard and determines that the use case is allowed only as a controlled pilot because confidential information may be processed.

Engineering reviews the connector model and finds that the assistant inherits user permissions from the document repository. That reduces some risk, but Engineering still restricts the pilot to one business unit, disables unapproved external plugins, and enables admin audit logs. Risk reviews the vendor’s data handling terms and threat models accidental oversharing, prompt injection through documents, and unauthorized connector expansion.

The pilot launches with user guidance, logging, and a named Business Owner. After 30 days, Risk reports no material incidents but identifies repeated attempts to use the assistant with restricted data. Governance updates the user guidance and requires a data-handling reminder before expansion. Engineering keeps connector approvals centralized until the control is proven stable.

Operational outputs

AI use case intake and disposition recorded.
Architecture, vendor, data, and access reviews completed.
Pilot restrictions and administrative controls evidenced.
Risk review completed before broad rollout.
Metrics updated for AI governance and adoption oversight.

Story 11: OT maintenance-window patch deferral

Situation

A monthly exposure review finds a High vulnerability on an OT historian that supports a substation operations view. The vendor patch is available, but the OT owner says the patch cannot be applied until the next approved maintenance window without risking operational disruption. The asset is adjacent to BES monitoring data but is not itself a BES Cyber System.

CERG flow pattern

Primary flow: F-04 Finding to Remediation, Exception, or Residual Risk

Supporting procedures and standards:

Walkthrough

Step	What happens	Primary owner	Record or evidence
1	Risk validates the scanner finding with OT-safe context: affected version, exploitability, network reachability, and whether the asset is BES Cyber System scope.	Risk Pillar / OT Risk Analyst	Finding Record
2	Engineering and OT operations confirm that immediate patching would disrupt the operational window and identify non-patch treatments.	Engineering Pillar / OT Security Engineer	Treatment analysis
3	Governance confirms the route: non-BES OT operational-window deferral, not a CIP deviation.	Governance Pillar / NERC-CIP Compliance Manager if needed	Routing note
4	Engineering implements compensating controls: restrict management access, block the vulnerable service path, confirm monitoring, and document rollback.	Engineering Pillar	Compensating-control evidence
5	Risk keeps the finding open, records the next maintenance window as the treatment date, and monitors for threat-intelligence changes.	Risk Pillar	Exposure pipeline update
6	If the asset is later determined to be BES Cyber System scope or the deferral would create a CIP compliance gap, Governance reroutes to the BES/CIP deviation path.	Governance Pillar	CIP applicability / deviation record
7	After the maintenance window, Engineering applies the patch, verifies service health, and supplies closure evidence.	Engineering Pillar	Closure evidence

Example day-in-the-life narrative

The scanner report arrives Monday morning, but the finding does not become a generic 30-day patch ticket. Risk checks reachability and confirms that the vulnerable service is only reachable from the OT management subnet. Engineering confirms that the affected historian feeds an operator dashboard and that an immediate reboot would interrupt a scheduled reliability test.

The OT Security Engineer proposes three non-patch treatments for the deferral window: block the vulnerable service from non-management subnets, require jump-host access for administration, and add a detection for unexpected connection attempts. Governance checks the asset classification and confirms this is a non-BES OT operational-window deferral. Because CIP compliance is not affected, the team does not open a CIP deviation; it documents the CIP applicability note and stores the evidence with the Finding Record.

The Business Owner accepts the short operational deferral only after seeing the compensating controls, the maintenance-window date, and the consequence if exploitation occurs. Risk does not close the finding. The exposure remains open with a deferral route, a named owner, and a review date. Two weeks later, threat intelligence reports active exploitation of the same product in the sector. Risk reopens the decision, Engineering adds a temporary allow-list rule, and the Business Owner confirms the maintenance window will not slip.

During the maintenance window, Engineering patches the historian, validates service health with OT operations, and captures version evidence. Governance verifies that the record names match the Record Catalog and that the closure evidence is audit-ready. The finding closes only after the patch and verification are complete.

Operational outputs

Finding Record with OT/BES scope determination.
Non-patch treatment analysis and compensating-control evidence.
Maintenance-window deferral route documented under PRC-VM §7.4.
CIP applicability note or CIP deviation record when applicable.
Business Owner consequence decision if residual risk remains during the deferral.
Verified closure evidence after patching.

Source: examples/day-in-the-life/README.md · Download .md · View on GitHub