Related with the following articles/posts:
Previous Series: Part 1: Executive Briefing
Previous Series: Part 2: National Risk, Threat Landscape, and the First 30 Days
Previous Series: Part-3: Target Architecture for IT, OT, Cloud, and Power Grid Environments
Previous Series: Part-4: Tools, Technologies, and Control Implementation Catalog
Previous Series: Part-5: SOC, Detection, Incident Response, Resilience, and Exercises
Previous Series: Part-6: AI, Governance, Procurement, and the 180-Day National Roadmap
Implementation Control Matrix
Use this as an internal checklist after publishing the blog series.
Each control should have:
- owner
- enforcement point
- evidence
- review frequency
- exception process
- residual risk statement
Control 1: Critical process ownership
Objective:
Identify the national services and physical processes where cyber compromise can create major public, safety, economic, or national impact.
Enforcement points:
- national critical infrastructure register
- utility risk register
- plant process inventory
- executive risk committee
Evidence:
- critical process list
- named business owner
- named OT owner
- consequence rating
- dependency map
Failure mode:
The organization secures systems based on technology importance instead of national consequence.
Control 2: OT asset inventory
Objective:
Maintain an accurate inventory of critical OT assets, versions, owners, zones, communication flows, and backup status.
Enforcement points:
- passive discovery platform
- CMDB
- engineering documentation
- plant walkdowns
Evidence:
- asset inventory export
- unknown asset report
- firmware and software list
- ownership field
- criticality field
- monthly reconciliation
Failure mode:
The inventory misses serial devices, spare controllers, relay settings, offline engineering laptops, or undocumented modems.
Control 3: IT/OT segmentation
Objective:
Prevent enterprise compromise from reaching control systems directly.
Enforcement points:
- enterprise-to-OT firewall
- OT DMZ
- proxies and brokers
- industrial firewalls
- router and switch ACLs
Evidence:
- zone and conduit diagram
- firewall rule export
- blocked direct access test
- quarterly rule review
- exception register
Failure mode:
A firewall exists, but broad rules allow direct access into OT.
Control 4: Vendor remote access
Objective:
Ensure vendor access is approved, MFA-protected, time-bound, recorded, and limited to named assets.
Enforcement points:
- remote access portal
- MFA
- PAM
- jump host
- ticketing system
- firewall policy
Evidence:
- access approval ticket
- MFA logs
- session recording
- target asset list
- monthly vendor account review
Failure mode:
A vendor VPN lands directly inside Level 2 or Level 1 with broad subnet access.
Control 5: OT identity and privileged access
Objective:
Prevent credential compromise from becoming OT control.
Enforcement points:
- separate or controlled OT identity boundary
- PAM
- MFA
- local admin password management
- privileged access review
- break-glass procedure
Evidence:
- privileged account inventory
- MFA enforcement report
- PAM session logs
- break-glass test record
- service account register
Failure mode:
Corporate identity compromise grants direct access to OT workstations or systems.
Control 6: Engineering workstation security
Objective:
Protect the systems used to configure controllers, relays, HMIs, and SCADA applications.
Enforcement points:
- application allowlisting
- endpoint hardening
- USB control
- local admin restriction
- jump host access
- backup images
- log forwarding
Evidence:
- hardening baseline
- allowlisting policy
- local admin review
- USB exception register
- golden image record
- restore test
Failure mode:
An engineering workstation becomes the bridge between attacker access and controller modification.
Control 7: Controller, RTU, IED, and relay protection
Objective:
Restrict and monitor changes to control logic, relay settings, firmware, and device configuration.
Enforcement points:
- controller ACLs where supported
- cell firewall
- approved engineering stations
- physical cabinet control
- change workflow
- logic backup
- checksum or integrity validation
Evidence:
- approved engineering source list
- controller configuration export
- logic backup
- relay setting backup
- change ticket
- integrity validation
Failure mode:
Anyone on the plant VLAN can reach a programming interface.
Control 8: OT monitoring and detection
Objective:
Detect unauthorized access, control writes, new devices, segmentation failures, abnormal engineering activity, and suspicious remote access.
Enforcement points:
- passive OT sensors
- SIEM
- packet capture
- jump host logs
- identity logs
- firewall logs
- detection catalog
Evidence:
- log source inventory
- sensor placement map
- detection catalog
- ATT&CK for ICS mapping
- alert tuning record
- detection test result
Failure mode:
Monitoring generates noise but misses process-relevant behavior.
Control 9: Vulnerability and patch management
Objective:
Identify and reduce vulnerabilities based on consequence, exploitability, exposure, and recoverability.
Enforcement points:
- passive vulnerability assessment
- vendor advisories
- CISA ICS advisories
- change management
- compensating controls
- exception register
Evidence:
- vulnerability report
- affected asset list
- remediation ticket
- mitigation evidence
- patch test result
- exception approval
Failure mode:
The team uses enterprise CVSS-only prioritization and misses high-consequence OT exposure.
Control 10: Backup and recovery
Objective:
Restore critical process-control functions from trusted backups during an incident.
Enforcement points:
- backup platform
- offline or immutable storage
- vendor backup tools
- spare hardware
- recovery runbook
- restore exercises
Evidence:
- backup inventory
- restore test report
- firmware and software dependency list
- recovery procedure
- spare hardware record
Failure mode:
Backups exist but cannot be restored under incident conditions.
Control 11: OT incident response
Objective:
Contain cyber incidents without creating unsafe physical process behavior.
Enforcement points:
- OT incident response plan
- severity model
- incident bridge
- safety approval process
- containment playbooks
- forensic evidence procedure
Evidence:
- incident ticket
- decision log
- timeline
- containment approval
- evidence package
- post-incident report
- remediation owners
Failure mode:
The SOC applies IT containment actions that destabilize operations.
Control 12: AI governance
Objective:
Use AI to support cybersecurity decisions without allowing unsafe autonomous control actions.
Enforcement points:
- AI use case register
- data classification
- approved AI platform
- human approval gates
- prompt and output logging
- model owner
- risk owner
Evidence:
- AI policy
- approved use case list
- data handling review
- human approval record
- AI output validation
- periodic review
Failure mode:
AI is connected to sensitive OT data or operational actions without governance.
Control 13: Secure procurement
Objective:
Ensure new ICS products and services can be secured, monitored, patched, supported, and recovered.
Enforcement points:
- procurement policy
- vendor security review
- contract language
- SBOM requirement where applicable
- vulnerability disclosure requirement
- secure configuration baseline
- end-of-life planning
Evidence:
- vendor security questionnaire
- SBOM or equivalent artifact
- secure configuration guide
- support lifecycle commitment
- incident notification clause
- remote support architecture approval
Failure mode:
The organization purchases systems that cannot meet minimum security and recovery expectations.
Control 14: Executive metrics
Objective:
Report cyber risk in terms of national service resilience.
Enforcement points:
- risk dashboard
- executive committee
- board or ministry reporting
- regulatory evidence pack
Evidence:
- asset coverage
- segmentation status
- vendor access metrics
- backup restore metrics
- detection test metrics
- vulnerability exceptions
- incident response exercise results
Failure mode:
Leadership receives alert counts instead of risk and resilience indicators.
Final use
This matrix should be reviewed quarterly.
Each control should have:
- owner
- current maturity score
- target maturity score
- funded remediation
- due date
- exception status
- residual risk
Top comments (0)