NIST SP 800-53 Rev5
720 records. Direct records match this source; context records explain their connections.
Read the first JSON page · Data retrieval guide
Mappings may provide partial coverage. Read mapping properties, residual requirements and source notes before relying on a connection.
control · Direct
AC-1 — Policy and Procedures
Policy and Procedures
control · Direct
AC-10 — Concurrent Session Control
Concurrent Session Control
control · Direct
AC-11 — Device Lock
Device Lock
control · Direct
AC-12 — Session Termination
Session Termination
control · Direct
AC-14 — Permitted Actions Without Identification or Authentication
Permitted Actions Without Identification or Authentication
control · Direct
AC-16 — Security and Privacy Attributes
Security and Privacy Attributes
control · Direct
AC-17 — Remote Access
Remote Access
control · Direct
AC-18 — Wireless Access
Wireless Access
control · Direct
AC-19 — Access Control for Mobile Devices
Access Control for Mobile Devices
control · Direct
AC-2 — Account Management
Account Management
control · Direct
AC-20 — Use of External Systems
Use of External Systems
control · Direct
AC-21 — Information Sharing
Information Sharing
control · Direct
AC-22 — Publicly Accessible Content
Publicly Accessible Content
control · Direct
AC-24 — Access Control Decisions
Access Control Decisions
control · Direct
AC-25 — Reference Monitor
Reference Monitor
control · Direct
AC-3 — Access Enforcement
Access Enforcement
control · Direct
AC-4 — Information Flow Enforcement
Information Flow Enforcement
control · Direct
AC-5 — Separation of Duties
Separation of Duties
control · Direct
AC-6 — Least Privilege
Least Privilege
control · Direct
AC-7 — Unsuccessful Logon Attempts
Unsuccessful Logon Attempts
control · Direct
AC-8 — System Use Notification
System Use Notification
control · Direct
AC-9 — Previous Logon Notification
Previous Logon Notification
control · Direct
AT-1 — Policy and Procedures
Policy and Procedures
control · Direct
AT-2 — Literacy Training and Awareness
Literacy Training and Awareness
control · Direct
AT-3 — Role-based Training
Role-based Training
control · Direct
AT-4 — Training Records
Training Records
control · Direct
AT-6 — Training Feedback
Training Feedback
control · Direct
AU-1 — Policy and Procedures
Policy and Procedures
control · Direct
AU-10 — Non-repudiation
Non-repudiation
control · Direct
AU-11 — Audit Record Retention
Audit Record Retention
control · Direct
AU-12 — Audit Record Generation
Audit Record Generation
control · Direct
AU-13 — Monitoring for Information Disclosure
Monitoring for Information Disclosure
control · Direct
AU-14 — Session Audit
Session Audit
control · Direct
AU-16 — Cross-organizational Audit Logging
Cross-organizational Audit Logging
control · Direct
AU-2 — Event Logging
Event Logging
control · Direct
AU-3 — Content of Audit Records
Content of Audit Records
control · Direct
AU-4 — Audit Log Storage Capacity
Audit Log Storage Capacity
control · Direct
AU-5 — Response to Audit Logging Process Failures
Response to Audit Logging Process Failures
control · Direct
AU-6 — Audit Record Review, Analysis, and Reporting
Audit Record Review, Analysis, and Reporting
control · Direct
AU-7 — Audit Record Reduction and Report Generation
Audit Record Reduction and Report Generation
control · Direct
AU-8 — Time Stamps
Time Stamps
control · Direct
AU-9 — Protection of Audit Information
Protection of Audit Information
control · Direct
CA-1 — Policy and Procedures
Policy and Procedures
control · Direct
CA-2 — Control Assessments
Control Assessments
control · Direct
CA-3 — Information Exchange
Information Exchange
control · Direct
CA-5 — Plan of Action and Milestones
Plan of Action and Milestones
control · Direct
CA-6 — Authorization
Authorization
control · Direct
CA-7 — Continuous Monitoring
Continuous Monitoring
control · Direct
CA-8 — Penetration Testing
Penetration Testing
control · Direct
CA-9 — Internal System Connections
Internal System Connections
control · Direct
CM-1 — Policy and Procedures
Policy and Procedures
control · Direct
CM-10 — Software Usage Restrictions
Software Usage Restrictions
control · Direct
CM-11 — User-installed Software
User-installed Software
control · Direct
CM-12 — Information Location
Information Location
control · Direct
CM-13 — Data Action Mapping
Data Action Mapping
control · Direct
CM-14 — Signed Components
Signed Components
control · Direct
CM-2 — Baseline Configuration
Baseline Configuration
control · Direct
CM-3 — Configuration Change Control
Configuration Change Control
control · Direct
CM-4 — Impact Analyses
Impact Analyses
control · Direct
CM-5 — Access Restrictions for Change
Access Restrictions for Change
control · Direct
CM-6 — Configuration Settings
Configuration Settings
control · Direct
CM-7 — Least Functionality
Least Functionality
control · Direct
CM-8 — System Component Inventory
System Component Inventory
control · Direct
CM-9 — Configuration Management Plan
Configuration Management Plan
control · Direct
CP-1 — Policy and Procedures
Policy and Procedures
control · Direct
CP-10 — System Recovery and Reconstitution
System Recovery and Reconstitution
control · Direct
CP-11 — Alternate Communications Protocols
Alternate Communications Protocols
control · Direct
CP-12 — Safe Mode
Safe Mode
control · Direct
CP-13 — Alternative Security Mechanisms
Alternative Security Mechanisms
control · Direct
CP-2 — Contingency Plan
Contingency Plan
control · Direct
CP-3 — Contingency Training
Contingency Training
control · Direct
CP-4 — Contingency Plan Testing
Contingency Plan Testing
control · Direct
CP-6 — Alternate Storage Site
Alternate Storage Site
control · Direct
CP-7 — Alternate Processing Site
Alternate Processing Site
control · Direct
CP-8 — Telecommunications Services
Telecommunications Services
control · Direct
CP-9 — System Backup
System Backup
control · Direct
IA-1 — Policy and Procedures
Policy and Procedures
control · Direct
IA-10 — Adaptive Authentication
Adaptive Authentication
control · Direct
IA-11 — Re-authentication
Re-authentication
control · Direct
IA-12 — Identity Proofing
Identity Proofing
control · Direct
IA-2 — Identification and Authentication (Organizational Users)
Identification and Authentication (Organizational Users)
control · Direct
IA-3 — Device Identification and Authentication
Device Identification and Authentication
control · Direct
IA-4 — Identifier Management
Identifier Management
control · Direct
IA-5 — Authenticator Management
Authenticator Management
control · Direct
IA-6 — Authentication Feedback
Authentication Feedback
control · Direct
IA-7 — Cryptographic Module Authentication
Cryptographic Module Authentication
control · Direct
IA-8 — Identification and Authentication (Non-organizational Users)
Identification and Authentication (Non-organizational Users)
control · Direct
IA-9 — Service Identification and Authentication
Service Identification and Authentication
control · Direct
IR-1 — Policy and Procedures
Policy and Procedures
control · Direct
IR-2 — Incident Response Training
Incident Response Training
control · Direct
IR-3 — Incident Response Testing
Incident Response Testing
control · Direct
IR-4 — Incident Handling
Incident Handling
control · Direct
IR-5 — Incident Monitoring
Incident Monitoring
control · Direct
IR-6 — Incident Reporting
Incident Reporting
control · Direct
IR-7 — Incident Response Assistance
Incident Response Assistance
control · Direct
IR-8 — Incident Response Plan
Incident Response Plan
control · Direct
IR-9 — Information Spillage Response
Information Spillage Response
control · Direct
MA-1 — Policy and Procedures
Policy and Procedures
control · Direct
MA-2 — Controlled Maintenance
Controlled Maintenance
control · Direct
MA-3 — Maintenance Tools
Maintenance Tools
control · Direct
MA-4 — Nonlocal Maintenance
Nonlocal Maintenance
control · Direct
MA-5 — Maintenance Personnel
Maintenance Personnel
control · Direct
MA-6 — Timely Maintenance
Timely Maintenance
control · Direct
MA-7 — Field Maintenance
Field Maintenance
control · Direct
MP-1 — Policy and Procedures
Policy and Procedures
control · Direct
MP-2 — Media Access
Media Access
control · Direct
MP-3 — Media Marking
Media Marking
control · Direct
MP-4 — Media Storage
Media Storage
control · Direct
MP-5 — Media Transport
Media Transport
control · Direct
MP-6 — Media Sanitization
Media Sanitization
control · Direct
MP-7 — Media Use
Media Use
control · Direct
MP-8 — Media Downgrading
Media Downgrading
control · Direct
PE-1 — Policy and Procedures
Policy and Procedures
control · Direct
PE-10 — Emergency Shutoff
Emergency Shutoff
control · Direct
PE-11 — Emergency Power
Emergency Power
control · Direct
PE-12 — Emergency Lighting
Emergency Lighting
control · Direct
PE-13 — Fire Protection
Fire Protection
control · Direct
PE-14 — Environmental Controls
Environmental Controls
control · Direct
PE-15 — Water Damage Protection
Water Damage Protection
control · Direct
PE-16 — Delivery and Removal
Delivery and Removal
control · Direct
PE-17 — Alternate Work Site
Alternate Work Site
control · Direct
PE-18 — Location of System Components
Location of System Components
control · Direct
PE-19 — Information Leakage
Information Leakage
control · Direct
PE-2 — Physical Access Authorizations
Physical Access Authorizations
control · Direct
PE-20 — Asset Monitoring and Tracking
Asset Monitoring and Tracking
control · Direct
PE-21 — Electromagnetic Pulse Protection
Electromagnetic Pulse Protection
control · Direct
PE-22 — Component Marking
Component Marking
control · Direct
PE-23 — Facility Location
Facility Location
control · Direct
PE-3 — Physical Access Control
Physical Access Control
control · Direct
PE-4 — Access Control for Transmission
Access Control for Transmission
control · Direct
PE-5 — Access Control for Output Devices
Access Control for Output Devices
control · Direct
PE-6 — Monitoring Physical Access
Monitoring Physical Access
control · Direct
PE-8 — Visitor Access Records
Visitor Access Records
control · Direct
PE-9 — Power Equipment and Cabling
Power Equipment and Cabling
control · Direct
PL-1 — Policy and Procedures
Policy and Procedures
control · Direct
PL-10 — Baseline Selection
Baseline Selection
control · Direct
PL-11 — Baseline Tailoring
Baseline Tailoring
control · Direct
PL-2 — System Security and Privacy Plans
System Security and Privacy Plans
control · Direct
PL-4 — Rules of Behavior
Rules of Behavior
control · Direct
PL-7 — Concept of Operations
Concept of Operations
control · Direct
PL-8 — Security and Privacy Architectures
Security and Privacy Architectures
control · Direct
PL-9 — Central Management
Central Management
control · Direct
PM-1 — Information Security Program Plan
Information Security Program Plan
control · Direct
PM-10 — Authorization Process
Authorization Process
control · Direct
PM-11 — Mission and Business Process Definition
Mission and Business Process Definition
control · Direct
PM-12 — Insider Threat Program
Insider Threat Program
control · Direct
PM-13 — Security and Privacy Workforce
Security and Privacy Workforce
control · Direct
PM-14 — Testing, Training, and Monitoring
Testing, Training, and Monitoring
control · Direct
PM-15 — Security and Privacy Groups and Associations
Security and Privacy Groups and Associations
control · Direct
PM-16 — Threat Awareness Program
Threat Awareness Program
control · Direct
PM-17 — Protecting Controlled Unclassified Information on External Systems
Protecting Controlled Unclassified Information on External Systems
control · Direct
PM-18 — Privacy Program Plan
Privacy Program Plan
control · Direct
PM-19 — Privacy Program Leadership Role
Privacy Program Leadership Role
control · Direct
PM-2 — Information Security Program Leadership Role
Information Security Program Leadership Role
control · Direct
PM-20 — Dissemination of Privacy Program Information
Dissemination of Privacy Program Information
control · Direct
PM-21 — Accounting of Disclosures
Accounting of Disclosures
control · Direct
PM-22 — Personally Identifiable Information Quality Management
Personally Identifiable Information Quality Management
control · Direct
PM-23 — Data Governance Body
Data Governance Body
control · Direct
PM-24 — Data Integrity Board
Data Integrity Board
control · Direct
PM-25 — Minimization of Personally Identifiable Information Used in Testing, Training, and Research
Minimization of Personally Identifiable Information Used in Testing, Training, and Research
control · Direct
PM-26 — Complaint Management
Complaint Management
control · Direct
PM-27 — Privacy Reporting
Privacy Reporting
control · Direct
PM-28 — Risk Framing
Risk Framing
control · Direct
PM-29 — Risk Management Program Leadership Roles
Risk Management Program Leadership Roles
control · Direct
PM-3 — Information Security and Privacy Resources
Information Security and Privacy Resources
control · Direct
PM-30 — Supply Chain Risk Management Strategy
Supply Chain Risk Management Strategy
control · Direct
PM-31 — Continuous Monitoring Strategy
Continuous Monitoring Strategy
control · Direct
PM-32 — Purposing
Purposing
control · Direct
PM-4 — Plan of Action and Milestones Process
Plan of Action and Milestones Process
control · Direct
PM-5 — System Inventory
System Inventory
control · Direct
PM-6 — Measures of Performance
Measures of Performance
control · Direct
PM-7 — Enterprise Architecture
Enterprise Architecture
control · Direct
PM-8 — Critical Infrastructure Plan
Critical Infrastructure Plan
control · Direct
PM-9 — Risk Management Strategy
Risk Management Strategy
control · Direct
PS-1 — Policy and Procedures
Policy and Procedures
control · Direct
PS-2 — Position Risk Designation
Position Risk Designation
control · Direct
PS-3 — Personnel Screening
Personnel Screening
control · Direct
PS-4 — Personnel Termination
Personnel Termination
control · Direct
PS-5 — Personnel Transfer
Personnel Transfer
control · Direct
PS-6 — Access Agreements
Access Agreements
control · Direct
PS-7 — External Personnel Security
External Personnel Security
control · Direct
PS-8 — Personnel Sanctions
Personnel Sanctions
control · Direct
PS-9 — Position Descriptions
Position Descriptions
control · Direct
PT-1 — Policy and Procedures
Policy and Procedures
control · Direct
PT-2 — Authority to Process Personally Identifiable Information
Authority to Process Personally Identifiable Information
control · Direct
PT-3 — Personally Identifiable Information Processing Purposes
Personally Identifiable Information Processing Purposes
control · Direct
PT-4 — Consent
Consent
control · Direct
PT-5 — Privacy Notice
Privacy Notice
control · Direct
PT-6 — System of Records Notice
System of Records Notice
control · Direct
PT-7 — Specific Categories of Personally Identifiable Information
Specific Categories of Personally Identifiable Information
control · Direct
PT-8 — Computer Matching Requirements
Computer Matching Requirements
control · Direct
RA-1 — Policy and Procedures
Policy and Procedures
control · Direct
RA-10 — Threat Hunting
Threat Hunting
control · Direct
RA-2 — Security Categorization
Security Categorization
control · Direct
RA-3 — Risk Assessment
Risk Assessment
control · Direct
RA-5 — Vulnerability Monitoring and Scanning
Vulnerability Monitoring and Scanning
control · Direct
RA-7 — Risk Response
Risk Response
control · Direct
RA-8 — Privacy Impact Assessments
Privacy Impact Assessments
control · Direct
RA-9 — Criticality Analysis
Criticality Analysis
control · Direct
SA-1 — Policy and Procedures
Policy and Procedures
control · Direct
SA-10 — Developer Configuration Management
Developer Configuration Management
control · Direct
SA-11 — Developer Testing and Evaluation
Developer Testing and Evaluation
control · Direct
SA-15 — Development Process, Standards, and Tools
Development Process, Standards, and Tools
control · Direct
SA-16 — Developer-provided Training
Developer-provided Training
control · Direct
SA-17 — Developer Security and Privacy Architecture and Design
Developer Security and Privacy Architecture and Design
control · Direct
SA-2 — Allocation of Resources
Allocation of Resources
control · Direct
SA-20 — Customized Development of Critical Components
Customized Development of Critical Components
control · Direct
SA-21 — Developer Screening
Developer Screening
control · Direct
SA-22 — Unsupported System Components
Unsupported System Components
control · Direct
SA-23 — Specialization
Specialization
control · Direct
SA-3 — System Development Life Cycle
System Development Life Cycle
control · Direct
SA-4 — Acquisition Process
Acquisition Process
control · Direct
SA-5 — System Documentation
System Documentation
control · Direct
SA-8 — Security and Privacy Engineering Principles
Security and Privacy Engineering Principles
control · Direct
SA-9 — External System Services
External System Services
control · Direct
SC-1 — Policy and Procedures
Policy and Procedures
control · Direct
SC-10 — Network Disconnect
Network Disconnect
control · Direct
SC-11 — Trusted Path
Trusted Path
control · Direct
SC-12 — Cryptographic Key Establishment and Management
Cryptographic Key Establishment and Management
control · Direct
SC-13 — Cryptographic Protection
Cryptographic Protection
control · Direct
SC-15 — Collaborative Computing Devices and Applications
Collaborative Computing Devices and Applications
control · Direct
SC-16 — Transmission of Security and Privacy Attributes
Transmission of Security and Privacy Attributes
control · Direct
SC-17 — Public Key Infrastructure Certificates
Public Key Infrastructure Certificates
control · Direct
SC-18 — Mobile Code
Mobile Code
control · Direct
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Direct
SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
Secure Name/Address Resolution Service (Authoritative Source)
control · Direct
SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver)
Secure Name/Address Resolution Service (Recursive or Caching Resolver)
control · Direct
SC-22 — Architecture and Provisioning for Name/Address Resolution Service
Architecture and Provisioning for Name/Address Resolution Service
control · Direct
SC-23 — Session Authenticity
Session Authenticity
control · Direct
SC-24 — Fail in Known State
Fail in Known State
control · Direct
SC-25 — Thin Nodes
Thin Nodes
control · Direct
SC-26 — Decoys
Decoys
control · Direct
SC-28 — Protection of Information at Rest
Protection of Information at Rest
control · Direct
SC-29 — Heterogeneity
Heterogeneity
control · Direct
SC-3 — Security Function Isolation
Security Function Isolation
control · Direct
SC-30 — Concealment and Misdirection
Concealment and Misdirection
control · Direct
SC-31 — Covert Channel Analysis
Covert Channel Analysis
control · Direct
SC-32 — System Partitioning
System Partitioning
control · Direct
SC-34 — Non-modifiable Executable Programs
Non-modifiable Executable Programs
control · Direct
SC-35 — External Malicious Code Identification
External Malicious Code Identification
control · Direct
SC-36 — Distributed Processing and Storage
Distributed Processing and Storage
control · Direct
SC-37 — Out-of-band Channels
Out-of-band Channels
control · Direct
SC-38 — Operations Security
Operations Security
control · Direct
SC-39 — Process Isolation
Process Isolation
control · Direct
SC-4 — Information in Shared System Resources
Information in Shared System Resources
control · Direct
SC-40 — Wireless Link Protection
Wireless Link Protection
control · Direct
SC-41 — Port and I/O Device Access
Port and I/O Device Access
control · Direct
SC-42 — Sensor Capability and Data
Sensor Capability and Data
control · Direct
SC-43 — Usage Restrictions
Usage Restrictions
control · Direct
SC-44 — Detonation Chambers
Detonation Chambers
control · Direct
SC-45 — System Time Synchronization
System Time Synchronization
control · Direct
SC-46 — Cross Domain Policy Enforcement
Cross Domain Policy Enforcement
control · Direct
SC-47 — Alternate Communications Paths
Alternate Communications Paths
control · Direct
SC-48 — Sensor Relocation
Sensor Relocation
control · Direct
SC-49 — Hardware-enforced Separation and Policy Enforcement
Hardware-enforced Separation and Policy Enforcement
control · Direct
SC-5 — Denial-of-service Protection
Denial-of-service Protection
control · Direct
SC-50 — Software-enforced Separation and Policy Enforcement
Software-enforced Separation and Policy Enforcement
control · Direct
SC-51 — Hardware-based Protection
Hardware-based Protection
control · Direct
SC-6 — Resource Availability
Resource Availability
control · Direct
SC-7 — Boundary Protection
Boundary Protection
control · Direct
SC-8 — Transmission Confidentiality and Integrity
Transmission Confidentiality and Integrity
control · Direct
SI-1 — Policy and Procedures
Policy and Procedures
control · Direct
SI-10 — Information Input Validation
Information Input Validation
control · Direct
SI-11 — Error Handling
Error Handling
control · Direct
SI-12 — Information Management and Retention
Information Management and Retention
control · Direct
SI-13 — Predictable Failure Prevention
Predictable Failure Prevention
control · Direct
SI-14 — Non-persistence
Non-persistence
control · Direct
SI-15 — Information Output Filtering
Information Output Filtering
control · Direct
SI-16 — Memory Protection
Memory Protection
control · Direct
SI-17 — Fail-safe Procedures
Fail-safe Procedures
control · Direct
SI-18 — Personally Identifiable Information Quality Operations
Personally Identifiable Information Quality Operations
control · Direct
SI-19 — De-identification
De-identification
control · Direct
SI-2 — Flaw Remediation
Flaw Remediation
control · Direct
SI-20 — Tainting
Tainting
control · Direct
SI-21 — Information Refresh
Information Refresh
control · Direct
SI-22 — Information Diversity
Information Diversity
control · Direct
SI-23 — Information Fragmentation
Information Fragmentation
control · Direct
SI-3 — Malicious Code Protection
Malicious Code Protection
control · Direct
SI-4 — System Monitoring
System Monitoring
control · Direct
SI-5 — Security Alerts, Advisories, and Directives
Security Alerts, Advisories, and Directives
control · Direct
SI-6 — Security and Privacy Function Verification
Security and Privacy Function Verification
control · Direct
SI-7 — Software, Firmware, and Information Integrity
Software, Firmware, and Information Integrity
control · Direct
SI-8 — Spam Protection
Spam Protection
control · Direct
SR-1 — Policy and Procedures
Policy and Procedures
control · Direct
SR-10 — Inspection of Systems or Components
Inspection of Systems or Components
control · Direct
SR-11 — Component Authenticity
Component Authenticity
control · Direct
SR-12 — Component Disposal
Component Disposal
control · Direct
SR-2 — Supply Chain Risk Management Plan
Supply Chain Risk Management Plan
control · Direct
SR-3 — Supply Chain Controls and Processes
Supply Chain Controls and Processes
control · Direct
SR-4 — Provenance
Provenance
control · Direct
SR-5 — Acquisition Strategies, Tools, and Methods
Acquisition Strategies, Tools, and Methods
control · Direct
SR-6 — Supplier Assessments and Reviews
Supplier Assessments and Reviews
control · Direct
SR-7 — Supply Chain Operations Security
Supply Chain Operations Security
control · Direct
SR-8 — Notification Agreements
Notification Agreements
control · Direct
SR-9 — Tamper Resistance and Detection
Tamper Resistance and Detection
risk · Context
Excessive privilege and wrong assignment of access rights
Overly broad or wrongly assigned access rights, applications/services running with excessive privileges, and failure to enforce least privilege — a compromise or insider then gains broad access to systems and data.
risk · Context
Abuse of rights, forged rights, and repudiation of actions
Authorized users or administrators exploit legitimate access beyond permitted scope, fabricate or forge credentials/rights to gain privileges, and repudiate performed actions — undermining accountability and audit-trail integrity.
risk · Context
Weak account provisioning/de-registration and access review
No formal user registration/de-registration procedure and no periodic access-rights review, so orphaned or excessive accounts accumulate and access is not revoked when roles change or personnel leave.
risk · Context
Unauthorized use of equipment and unauthorized access escalation
Use of systems, networks, or devices without authorization, and users with authorized access reaching resources that exceed their authorization, potentially to exfiltrate data or conduct attacks.
risk · Context
Weak authentication and password management
Absent password policy, no MFA, credentials transmitted in clear text, and no session lock/logout on unattended workstations, making account compromise, brute-force login, and session hijacking easy.
risk · Context
Adversarial attacks, data poisoning and prompt injection
Data-poisoning corrupts training data and embeds backdoors; adversarial evasion, prompt injection, and jailbreaks fool deployed models at inference; model extraction steals proprietary weights/logic — enabling harmful or policy-violating outputs.
risk · Context
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · Context
AI endpoint abuse, scraping and model extraction
Adversaries scrape inference endpoints at scale to extract model behaviour or proprietary data, exhaust compute budgets through unbounded consumption, or harvest system prompts and technical details disclosed in outputs or documentation, degrading service and eroding competitive and security posture.
risk · Context
GPAI transparency, systemic-risk and synthetic-content obligations
GPAI providers failing transparency/copyright/training-data obligations; systemic-risk models (>10^25 FLOPs) lacking red-teaming, incident reporting, and cybersecurity; unlabeled deepfake/synthetic content; and concentration of GPAI capability creating ecosystem single points of failure.
risk · Context
Insecure AI-generated code and hallucinated or typosquatted dependencies
Code-generating AI produces insecure defaults (injection-prone queries, weak authentication and session handling, unsafe logging) or specifies non-existent, hallucinated, or typosquatted packages that attackers pre-register, introducing vulnerabilities and malicious dependencies into production software.
risk · Context
AI privacy leakage and re-identification
Model inversion and membership-inference attacks reconstruct training data or reveal individuals in the training set; AI inference re-identifies anonymized data and infers sensitive attributes; training on data without consent/legal basis creates regulatory liability.
risk · Context
AI supply-chain compromise and provider concentration
Because the organization relies on third-party pretrained models, datasets, and libraries that may carry backdoors, malicious code, or bias, and concentrates on a few external AI API providers, AI-dependent workflows are exposed to both supply-chain compromise and provider outage or insolvency, resulting in compromised model behaviour or sudden loss of AI capability.
risk · Context
Aging hardware with no periodic replacement scheme
Because maintenance routines and replacement schedules are absent, equipment is run beyond its reliable service life, so hardware fails - including correlated, pervasive disk failures from same-batch aging - resulting in outages and data loss.
risk · Context
Incomplete asset inventory and classification
No authoritative inventory of information and associated assets, missing ownership, acceptable-use, classification, labelling, or handling rules — preventing effective protection, risk assessment, and secure disposal.
risk · Context
Uncontrolled copying to removable media / unmanaged software installs
Absence of controls over copying data to removable devices, and users freely downloading/installing untested or unlicensed software, expands the attack surface and introduces malicious or unlicensed code into the environment.
risk · Context
Inadequate security awareness and training
Personnel lacking security awareness and training are more likely to make harmful mistakes, misconfigure systems, or be deceived — providing weak human defence and undermining every technical control. Includes insufficient privacy training.
risk · Context
No acceptable-use policy for messaging and telecoms
Because acceptable-use policies for email, messaging, and telecommunication services are absent, personnel use insecure channels without guidance, so sensitive information is inadvertently or deliberately disclosed through unsanctioned communications.
risk · Context
Phishing, spear-phishing and social engineering
Adversary counterfeits trustworthy communications (email, phone, spoofed websites) to trick individuals — including high-value executives — into revealing credentials or sensitive information, or into enabling wire-transfer/BEC fraud.
risk · Context
Missing role-based and ongoing security/privacy training
Because no role-based training program or ongoing awareness refresh exists for staff handling sensitive data or privileged systems, personnel cannot execute security procedures correctly or recognize evolving attacks, so avoidable errors and successful social-engineering compromises follow.
risk · Context
User error and mishandling of sensitive information
Authorized users make mistakes — incorrect data entry, misconfiguration, improper procedures, incorrect privilege settings, or spilling/mishandling sensitive information — causing harm to information assets without malicious intent.
risk · Context
IT resilience failure — unplanned outage, data loss, slow recovery
Critical technology infrastructure or applications experience unplanned outages, data loss, or prolonged recovery times — including failure of DR systems to activate — disrupting operations and harming stakeholders.
risk · Context
Absent or untested business continuity / disaster recovery plan
No BCP/DR plan, or plans that exist but have never been exercised end-to-end, so a natural disaster, pandemic, civil unrest, or infrastructure failure disables critical processes with no tested recovery path.
risk · Context
Single-site / single-region / single-supply concentration
Headquarters, data centers, or manufacturing concentrated in one region, single power feed or network path with no redundancy, and no failover — so one catastrophe or outage disables the whole service. Includes backup-facility loss destroying backups.
risk · Context
Client suitability, disclosure and fiduciary breaches
Recommending unsuitable products, failing to disclose conflicts of interest, breaching fiduciary duty, KYC failures, inadequate disclosure of fees/risks, negligent advisory activities, and product flaws causing systematic customer harm.
risk · Context
Improper business or market practices
Losses from antitrust violations, market manipulation (spoofing, layering, front-running), benchmark/rate rigging, unlicensed business activity, and sanctions/export-control violations in the conduct of business.
risk · Context
Intellectual property loss or infringement
Patent, trade-secret, copyright, or trademark infringement claims (competitors or NPEs), loss of key IP through invalidity rulings, inadequate protection of proprietary technology, or inability to enforce own IP against infringers.
risk · Context
Litigation, investigation and enforcement exposure
Adverse judgments, class actions, contract/IP disputes, government subpoenas, DOJ/FTC/SEC investigations, consent decrees, or deferred-prosecution agreements imposing penalties, remediation, and management distraction.
risk · Context
Lack of independent audit and compliance review
Because independent internal and external audit and review of information security are not performed, control deficiencies and non-conformities are neither detected nor challenged, so weaknesses persist unremediated and management and the board lose reliable assurance over control effectiveness.
risk · Context
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · Context
Internet-exposed or misconfigured systems
Adversary gains access through the Internet to systems not authorized for Internet connectivity or that do not meet configuration requirements, and exploits attacks over unauthorized ports, protocols, and services.
risk · Context
Poor configuration management and insecure baseline drift
Without documented, enforced baseline configurations and change control, systems drift into insecure states, contain unauthorized changes, or expose unnecessary network services, expanding attack surface.
risk · Context
Absent or weak change-control procedures
Changes to systems, software, hardware, or configurations without formal approval and testing (including unauthorized or poorly tested hardware/config changes) introduce new vulnerabilities, instability, or failed releases.
risk · Context
Credentials and sensitive data transmitted in clear text
Authentication credentials or sensitive system communications transmitted unencrypted over networks, and absence of mutual sender/receiver authentication, enable interception, credential theft, and spoofing.
risk · Context
Compromised or counterfeit certificates / certificate authority
Adversary counterfeits or compromises a certificate authority so that malware or connections appear legitimate, defeating trust in TLS and code-signing and enabling man-in-the-middle or malicious-code delivery.
risk · Context
Weak or absent encryption and key management
Sensitive data stored or transmitted without adequate encryption, or use of weak/flawed cryptography and poor key generation, storage, rotation, and destruction — enabling interception, disclosure, or tampering of data.
risk · Context
Attacks by capable, motivated threat actors
Because capable, motivated threat actors - outsiders, privileged and non-privileged insiders, organized groups, competitors, malicious partners or suppliers, and nation-states - actively target the organization's cyber resources, deliberate attacks are attempted against its systems and data, resulting in compromise, disruption, or theft when defenses are outmatched.
risk · Context
Coordinated multi-stage / APT campaigns
Adversary coordinates continuous, adaptive, multi-staged campaigns (hopping across systems, combining insider/outsider/supply-chain vectors, spreading from existing presence) to persist and progressively undermine mission/business functions.
risk · Context
Adversary reconnaissance and information gathering
Because adversaries scan perimeters, sniff exposed networks, mine open-source and public information, and surveil personnel and processes, they build a detailed map of the IT environment and its weaknesses, resulting in better-targeted, more likely-to-succeed follow-on attacks.
risk · Context
Unauthorized disclosure / breach of sensitive information
Unauthorized disclosure of information to parties not entitled to receive it, whether by insecure controls (insecurity), spillage, or authorized users induced to expose data — resulting in identity theft, economic loss, and loss of trust.
risk · Context
Corruption or integrity loss of critical data
Intentional or accidental alteration, deletion, defacement, or injection of false-but-believable data into systems (including web defacement and data from untrustworthy sources) renders data inaccurate and erodes confidence in it.
risk · Context
Excessive collection, purpose creep and secondary use
Collecting more personal data than necessary (data-minimization failure) and using it for purposes materially different from those disclosed without fresh notice/consent, expanding attack surface and violating purpose-limitation.
risk · Context
Data exfiltration and theft of information by attackers
Adversary (outsider, insider, nation-state, or competitor) installs malware or sniffers to locate and exfiltrate sensitive/proprietary information, or steals data by external actors — including systems-security losses from hacking.
risk · Context
Undocumented data inventory and unmapped data flows
No authoritative record of what personal data is held, where, who accesses it, and how it flows to processors/sub-processors and across borders — preventing risk assessment, DSR fulfilment, and enforcement of privacy obligations.
risk · Context
Privacy harms: distortion, stigmatization, unwarranted restriction
Processing inaccurate/out-of-context data (distortion), attaching negative social labels (stigmatization), or denying services based on personal data without justification (unwarranted restriction / algorithmic gatekeeping) — causing discrimination and economic loss.
risk · Context
Privacy-program non-compliance (GDPR, CCPA, state laws)
Failure to honour data-subject rights (access, deletion, portability, restriction) on time, missing lawful-basis/consent documentation, defective consent mechanisms, invalid cross-border transfer mechanisms, or inadequate notices — driving fines and private rights of action.
risk · Context
Re-identification and unanticipated revelation from data
Insufficient de-identification/pseudonymization, plus inference or linkage attacks and metadata leakage, re-identify individuals or reveal information they did not intend to disclose — causing embarrassment, harm, and regulatory exposure.
risk · Context
Residual data on improperly disposed or re-used media
Retrieval of recycled or discarded media, and disposal/reuse of storage without proper erasure, exposes residual sensitive information; also insecure/incomplete data deletion in multi-tenant/cloud environments.
risk · Context
Unlawful retention or premature deletion of records
Retaining personal data beyond necessity/mandated schedules (privacy and breach risk) or deleting records before required retention periods (litigation-hold, regulatory, tax risk); records-management policy not enforced technically.
risk · Context
Excessive surveillance, appropriation and induced disclosure
Pervasive monitoring beyond stated purpose (behavioral analytics, always-on telemetry, employee monitoring), using identity/data for organizational benefit without consent, and coercing individuals to over-share — causing chilling effects and loss of autonomy.
risk · Context
Inadequate transparency, notice and deceptive privacy communications
Failure to give clear, timely notice of collection, use, retention, and sharing; misleading or dark-pattern consent flows; and failure to disclose automated decision-making — undermining meaningful consent and compounding power imbalance.
risk · Context
Physical climate risk to facilities and supply chains
Extreme weather (flooding, wildfires, hurricanes, heat stress), sea-level rise, and resource scarcity damage owned/leased facilities, disrupt supplier operations, and impair logistics beyond insurance coverage.
risk · Context
Climate transition risk — carbon pricing and stranded assets
Carbon taxes, cap-and-trade, and mandatory Scope 1-2-3 reporting increase operating costs or strand carbon-intensive assets; failure to credibly plan a net-zero transition jeopardizes access to capital and changing consumer preferences.
risk · Context
Overstatement of assets/revenue (existence & occurrence)
Revenue, receivables, inventory, capitalized assets, prepaid expenses, treasury investments, or tax assets recorded without underlying existence or occurrence — inflating the balance sheet and income statement.
risk · Context
Financial-statement fraud and management override
Intentional misstatement through fictitious revenue, phantom inventory/assets, ghost-employee payroll, or management override of controls — inflating results and deceiving investors and regulators.
risk · Context
Ineffective ICFR / undisclosed material weakness
Because internal control over financial reporting is not maintained effectively - material weaknesses undetected or undisclosed and certifications signed despite known deficiencies - financial statements may be materially misstated and filings delayed or restated, resulting in SEC enforcement, delisting, securities-fraud liability, and loss of investor confidence.
risk · Context
Manual journal entries and management-override risk
Manual/automated journal entries posted with transposition errors, wrong account codes, or amounts; recurring entries not updated; and top-side entries used to override controls and manage earnings at period-end.
risk · Context
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Context
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
risk · Context
Liquidity, capital-structure and refinancing risk
Cash-flow shortfall from working-capital deterioration, covenant breaches accelerating debt, loss of revolving credit, or capital-market disruption; debt maturity walls and downgrades limiting refinancing at acceptable terms; insufficient capital to absorb losses.
risk · Context
External fraud — third-party theft, forgery, payment and account fraud
Third parties defraud the entity: cheque/payment-card forgery, counterfeit currency, identity theft, account takeover with stolen credentials, fraudulent loan applications, and first-party (bust-out) fraud by customers.
risk · Context
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Context
Unauthorized activity — rogue trading, position mismarking, concealment
Losses from transactions not reported or of an unauthorized type, deliberate mismarking of positions, fictitious trade bookings to conceal losses, and circumvention of position/risk limits without disclosure (e.g. rogue trader).
risk · Context
Organizational change and transformation failure
Significant structural or cultural change (restructuring, ERP/digital transformation) causes employee resistance, productivity loss, or talent departures that undermine the entity’s capacity to adapt to strategic imperatives.
risk · Context
Missing or insufficient security and privacy policies
Because documented, approved, and enforced security and privacy policies are missing and roles and duties are undefined, personnel operate without guidance on required controls and behaviours, so controls are applied inconsistently and accountability gaps leave violations undetected and unaddressed.
risk · Context
Innovation and R&D governance failure
Insufficient investment in or poor governance of innovation and R&D pipelines results in loss of competitive differentiation, failure to meet customer expectations, and premature obsolescence of products and services.
risk · Context
Weak internal control environment enabling fraud and error
Because the internal control environment is weak - segregation of duties absent, authorization frameworks inadequate, and tone at the top poor - fraudulent and erroneous transactions can be initiated and concealed, resulting in material misstatement and financial, regulatory, and reputational loss.
risk · Context
Discrimination, harassment and hostile-workplace culture
Systemic harassment or discrimination (race, gender, age, disability, etc.), pay-equity violations, retaliation, and inadequate speak-up channels resulting in regulatory action, litigation, attrition, and reputational harm.
risk · Context
Insufficient personnel screening and vetting
Failure to vet employees, contractors, or third parties before granting access enables insider threats or introduces compromised individuals; adversaries may deliberately place subverted individuals into (privileged) positions.
risk · Context
Missing security terms in contracts and no disciplinary process
Employment and supplier contracts omit security/confidentiality obligations, and there is no disciplinary process for security violations — removing legal recourse and the deterrent effect against repeat offenders.
risk · Context
Critical talent loss, scarcity and succession gaps
Departure of key executives or irreplaceable specialists without succession or knowledge-transfer plans, plus inability to recruit/retain scarce skills (cyber, data, AI/ML), causing loss of institutional knowledge and execution capacity. Also covers loss of key personnel disrupting operations dependent on specialist knowledge.
risk · Context
Workplace health, safety and well-being failures
Workplace accidents, occupational illness, missing PPE, OHS-regulation violations, premises-liability incidents, and burnout leading to injury claims, workers-compensation, regulatory penalties, and productivity loss.
risk · Context
Failure to detect, assess, and notify breaches on time
Failure to detect, assess, and notify affected individuals and regulators of personal-data breaches within required timeframes and content (GDPR Art.33/34, HIPAA breach rule), resulting in sanctions and compounded individual harm.
risk · Context
No or insufficient incident-response procedures
Without documented, tested incident-response procedures, breaches and failures are handled inconsistently, slowly, or ineffectively, prolonging exposure and amplifying loss.
risk · Context
Missing or insufficient logging and audit trails
Absence of logging/audit trails means unauthorized activity cannot be detected, investigated, or attributed, and adversary actions (obfuscation of intrusion detection, tampering with logs) go unnoticed.
risk · Context
No security monitoring or supervision of privileged activity
Absence of monitoring mechanisms and supervision of personnel actions (especially privileged users) allows undetected misuse, and no process exists to supervise and escalate detected security breaches.
risk · Context
Cloud multi-tenancy isolation and data-scavenging exploits
Adversary exploits multi-tenancy in a cloud environment to observe organizational processes, violates isolation mechanisms, or scavenges data used and deleted by cloud processes, compromising confidentiality and availability.
risk · Context
Denial-of-service and system saturation
Simple, targeted, or distributed denial-of-service attacks, wireless jamming, and saturation of systems or networks (adversarial or excessive legitimate load) make resources unavailable to intended users.
risk · Context
Communications interception, eavesdropping and man-in-the-middle
Passive monitoring/sniffing of communications, interception of unencrypted or weakly encrypted channels, wireless interception, and man-in-the-middle attacks capture or corrupt transmitted data — including TEMPEST-type emanation capture.
risk · Context
Poor network architecture and unprotected public connections
Because externally-facing connections lack perimeter controls (firewalls, DMZ) and the network lacks segmentation, redundancy, and defense-in-depth, attackers can breach the boundary and move laterally and single points of failure go unmitigated, resulting in intrusion, data exfiltration, and outage.
risk · Context
Remote-work, mobile and split-tunneling exposure
Uncontrolled work outside the premises, split-tunneling, and exploitation of mobile devices/personal systems outside physical and firewall protection expose information through insecure environments and reintroduce compromised devices into the enterprise.
risk · Context
Session hijacking and unauthorized-protocol egress
Adversary hijacks established legitimate sessions (externally or internally based) and conducts attacks/exfiltration using unauthorized ports, protocols, and permitted information flows across the perimeter.
risk · Context
Acceptance of data from untrustworthy sources
Injection or acceptance of data from untrusted or malicious sources (including position-detection/tracking data) causes incorrect processing or decisions and can seed downstream integrity loss.
risk · Context
Core process breakdown and inability to scale
Poorly designed, undocumented, or poorly executed business processes lead to errors, rework, cost overruns, service failures, and inability to scale operations reliably; large change programs fail to deliver benefits on time and budget.
risk · Context
Trade-counterparty performance and settlement disputes
Counterparty default on OTC derivatives, settlement disputes with brokers/custodians, failure of a central counterparty, netting/close-out disputes, and margin-call miscalculations cause direct losses.
risk · Context
Client intake, documentation and account-management failures
Missing signed agreements, incomplete legal/ISDA documentation, unretained KYC/AML records, misfiled client files, unauthorized access to client accounts, and negligent loss of client assets held in custody.
risk · Context
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · Context
Physical and cyber-physical attacks on facilities and infrastructure
Adversary conducts physical attacks on facilities (arson) or supporting infrastructure (cuts power/water), or cyber-physical attacks (remotely altering HVAC), damaging systems and supporting utilities.
risk · Context
Physical damage to assets from disaster, terrorism or vandalism
Loss or damage to facilities, equipment, or physical property from natural disaster (earthquake, flood, hurricane, wildfire), terrorism, civil unrest, vandalism, utility-infrastructure damage, vehicle/aircraft collision, or environmental contamination.
risk · Context
Environmental degradation of equipment (dust, humidity, temperature, EMI)
Equipment sited without environmental controls suffers from dust, corrosion, freezing, humidity, voltage or temperature variation, and electromagnetic/thermal radiation or EMP, causing malfunction or failure.
risk · Context
Inadequate protection against fire, flood and physical hazards
Absence of fire suppression, smoke detection, flood barriers, or drainage in facilities housing information assets, and poor cabling infrastructure susceptible to damage, tapping, or accidental disconnection.
risk · Context
Inadequate physical protection and access controls
Buildings and sensitive areas lacking perimeter security, key-card/lock/mantrap controls, or supervision of visitors and cleaning/outside staff allow unauthorized physical access to equipment and media — including tailgating past physical checks.
risk · Context
Remote spying and shoulder-surfing of screens/documents
Observation of screens, documents, or activities from a distance (shoulder surfing, optical surveillance) and interception of compromising emanation signals capture sensitive information without system access.
risk · Context
Theft of equipment, media or unattended devices
Physical stealing of storage media, printouts, or computing/network equipment (including unattended laptops outside the perimeter), potentially exposing stored data. Unprotected storage locations increase exposure.
risk · Context
Cross-border personal-data transfer without safeguards
Transferring personal data to jurisdictions lacking equivalent protection without SCCs, BCRs, adequacy decisions, or other recognized mechanisms, exposing individuals and the organization to legal risk.
risk · Context
Erosion of individual trust and confidence in data practices
Systemic failure to meet reasonable privacy expectations undermines confidence in products and institutions, causing disengagement, reputational damage, and reduced adoption — an organizational as well as individual harm.
risk · Context
Absence of privacy-by-design and default
Because systems and products are built without embedding privacy controls at the architecture level, privacy protections are bolted on after launch rather than applied by default, so personal data is over-collected and exposed and costly manual remediation is required.
risk · Context
Power imbalance and loss of self-determination over personal data
Structural informational asymmetry (take-it-or-leave-it consent, opaque algorithmic decisions) and inability to correct, delete, or restrict processing deprive individuals of meaningful control over their own data and narrative.
risk · Context
Brand and reputational crisis
Product-safety/quality failures, executive misconduct, data breaches, adverse media, or viral social-media/activist campaigns erode customer trust, investor confidence, partnerships, and brand equity — with long-term value loss exceeding near-term financial impact.
risk · Context
Stakeholder trust and social-license erosion
Gradual loss of trust and social license among customers, employees, investors, regulators, and communities — from perceived values misalignment, poor ESG/governance conduct, or repeated service failures — weakening stakeholder relationships and long-term enterprise value even absent a single acute crisis.
risk · Context
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Context
Applications running with excessive privilege / insecure design
Applications or services running under privileged accounts, opening unnecessary network connections, or lacking secure-by-design architecture mean a single compromise grants broad system access and expands attack surface.
risk · Context
Malware delivery, insertion and compromise of systems
Adversary crafts and delivers known, modified, or targeted malware (via email, web, removable media, or downloadable software) and compromises system software to take control, exfiltrate data, or degrade functions.
risk · Context
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
risk · Context
Vulnerabilities introduced during software development
Inherent weaknesses in programming languages and development environments introduce errors and exploitable vulnerabilities into software products, and software malfunctions cause incorrect outputs, crashes, or security weaknesses.
risk · Context
Product, customer or market concentration
Revenue or gross profit concentrated in a single product line, customer, channel, or geography; loss of one major customer or an adverse regulatory change to a dominant product creates existential revenue risk.
risk · Context
Geopolitical, macroeconomic and sovereign risk
Armed conflict, political instability, sanctions, trade-policy reversals (tariffs, export bans, data-localization, forced tech transfer), expropriation/nationalization, and adverse macroeconomic cycles disrupt operations, supply chains, and cost structures.
risk · Context
Strategic misalignment and execution failure
Because strategic objectives are poorly defined, internally inconsistent, or misaligned with mission and stakeholders, approved strategies cannot be executed - resource gaps and weak governance of change compound the shortfall - resulting in resource misallocation, missed objectives, and value destruction.
risk · Context
Hardware and equipment failure
Malfunction or breakdown of storage, processing, communications, sensor, controller, or display equipment (aging, resource depletion, disk errors) disrupting availability or integrity — including intermittent/degraded operation producing incorrect results.
risk · Context
Illegal processing of personal or sensitive data
Processing personal or sensitive data without legal authority, consent, or in violation of regulatory requirements — a data-protection breach with legal, privacy, and reputational consequences.
risk · Context
Loss of essential services (power, HVAC, telecoms)
Interruption of power supply, air-conditioning/water utilities, or telecommunications — from unstable grids, single power feeds, UPS/generator failure, or carrier/fiber outages — stops operations or harms equipment and personnel.
risk · Context
Loss of system maintainability
Loss of the ability to maintain, update, or repair information systems due to missing documentation, tools, skills, or unversioned software — leaving systems unpatchable and increasingly fragile over time.
risk · Context
Software and information-system failure
Failure or malfunction of operating-system, networking, or application software (defects, resource depletion, failed releases) causing loss of availability/integrity and impeding mission/business functions — including core banking/payments outages.
risk · Context
Use of unlicensed, counterfeit or pirated software
Fraudulent copying of software and deployment of pirated/counterfeit software (unlicensed or inadequately controlled) that may lack security patches or contain malicious code — a legal and security exposure.
risk · Context
Critical vendor failure, insolvency or concentration
A key supplier, SaaS provider, or outsourced partner becomes insolvent, exits the market, or suffers a prolonged outage; sole-source and shared-tier concentration (multiple tier-1 vendors on a common tier-2) creates hidden single points of failure with no backup.
risk · Context
Supply-chain disruption of critical inputs
Geopolitical events, natural disasters, port congestion, or logistics failures interrupt supply of critical raw materials or components (semiconductors, rare earths); just-in-time models are exposed to demand spikes.
risk · Context
Malicious supply-chain injection of tampered hardware/software
Adversary creates false-front suppliers or intercepts the supply chain to insert counterfeit or tampered hardware, corrupted software/firmware, or malicious components into products and information systems.
risk · Context
Third-party compliance failure creating vicarious liability
A vendor, subcontractor, or channel partner violates labor, environmental, anti-bribery (FCPA/UKBA), or data-protection rules, exposing the company to liability and reputational harm; fourth-party/N-tier dependencies are opaque.
risk · Context
Vendor/outsourcing service non-performance and disputes
Outsourced processing, IT, payroll/HR, print/mail, or sub-custodian providers fail to meet service levels, deliver defective software, make incorrect payments, or breach contractual deliverables, causing processing errors, outages, and loss.
risk · Context
Weak supplier security requirements and monitoring
Because supplier contracts omit security requirements and SLAs and third-party service delivery is not monitored, processors and sub-processors operate without equivalent, audited obligations, so third-party weaknesses and breaches propagate into the organization undetected.
risk · Context
Inadequate vulnerability scanning and pre-release testing
Software released without adequate testing, and no regular vulnerability scanning or penetration testing, leaves exploitable defects undiscovered until they manifest — or are exploited — in production.
risk · Context
Exploitation of known, unpatched vulnerabilities
Use of software with publicly known, unpatched flaws (CVEs) that adversaries readily exploit — including recently discovered vulnerabilities exploited before mitigations are in place, and internal-system vulnerability exploitation.
risk · Context
Zero-day exploitation
Adversary employs attacks that exploit as-yet-unpublicized vulnerabilities (targeted, based on reconnaissance, or nontargeted), compromising systems before any patch or signature exists.
standard · Direct
NIST SP 800-53 Rev5
NIST SP 800-53 Rev 5 — Security and Privacy Controls
unified · Context
UC-ACCESS-01 — Provision and deprovision accounts through a managed lifecycle
All accounts are created only on a documented, owner-approved request that specifies role-based entitlements and is uniquely attributable to an individual or service. Access is modified on role change and disabled or removed within one business day of termination or loss of authorization, with dormant accounts automatically disabled after a defined period. All provisioning, modification, and deprovisioning events are logged and retained as evidence.
unified · Context
UC-ACCESS-03 — Enforce least privilege, need-to-know, and segregation of duties
A documented access control policy grants access strictly on business need-to-know, with entitlements defined through roles that default to least privilege. Segregation-of-duties conflicts (e.g., request versus approve, develop versus deploy) are defined in a conflict matrix, enforced in systems, and mitigated with compensating controls where unavoidable. Role and entitlement definitions are approved by data or system owners and re-approved whenever they change.
unified · Context
UC-ACCESS-05 — Enforce approved authorizations for information and functions
Systems mediate every access attempt through a tamper-resistant, always-invoked enforcement mechanism that applies approved authorizations before granting access to information or functions. Restrictions use roles and security attributes bound to data and subjects, limiting access to sensitive information, source code, and administrative functions to explicitly authorized identities. Enforcement rules are applied consistently across applications, databases, and infrastructure and are tested for effectiveness.
unified · Context
UC-ACCESS-06 — Manage unique identities and identifiers end to end
Every user, service, and device is assigned a unique identifier from an authoritative source; shared or group identifiers are prohibited except under documented approval with compensating controls. Identifiers are issued through a controlled process, mapped to accountable owners, deactivated promptly when no longer needed, and not reused for a defined period.
unified · Context
UC-ACCESS-07 — Proof identities before binding credentials
The identity of users is verified through documented evidence checks proportional to the assurance level of the access requested before initial credentials are issued. The proofed identity is bound to its credentials and recorded, and re-proofing occurs on credential recovery or other high-risk changes.
unified · Context
UC-ACCESS-08 — Manage and protect authenticators across their lifecycle
Authenticators (passwords, tokens, keys, certificates) are issued through a verified process, with vendor defaults changed before use and minimum strength requirements enforced. Authentication information is protected in storage (salted hashing or encryption) and in transmission, masked during entry, and never embedded in code or scripts. Authenticators are revoked on compromise or separation and rotated at defined intervals or events.
unified · Context
UC-ACCESS-09 — Authenticate all users with multi-factor authentication
Every user is uniquely identified and authenticated before access, with multi-factor authentication enforced for remote access, privileged access, and access to sensitive data environments. Authentication follows secure log-on practices: credentials are validated only over protected channels, and federated identity assertions (e.g., SAML/OIDC tokens) are signed, protected, and verified. External and non-organizational users are held to the same authentication rigor, with authentication strength documented against the risk of the interaction.
unified · Context
UC-ACCESS-10 — Authenticate devices and services before granting connections
Devices and services (non-person entities) are uniquely identified and mutually authenticated before local, remote, or network connections are established, using cryptographically verifiable credentials such as certificates or managed service identities. Shared static secrets are prohibited or vaulted, and non-person credentials are inventoried and rotated.
unified · Context
UC-ACCESS-11 — Defend logons against brute-force and anomalous attempts
Accounts lock or are throttled after a defined number of consecutive failed logon attempts for a set duration or until administrator release. Risk-based signals such as location, device, and behavior trigger adaptive responses including step-up authentication, additional verification, or denial for anomalous logon attempts. Lockout and anomaly events are logged for review.
unified · Context
UC-ACCESS-12 — Lock, limit, and terminate user sessions
Sessions lock with a pattern-hiding display after a defined period of inactivity and require re-authentication to resume. Sessions terminate automatically on defined conditions such as extended inactivity, and concurrent sessions are limited per account. Re-authentication is required for sensitive operations, privilege changes, or after defined intervals.
unified · Context
UC-ACCESS-13 — Notify users of system terms and previous logon activity
An approved system-use notification is displayed before logon, stating monitoring, usage terms, and privacy expectations, and requiring acknowledgment where mandated. Upon successful logon, the system displays the date and time of the user's last logon, and failed attempts where supported, so users can detect unauthorized use of their accounts.
unified · Context
UC-ACCESS-14 — Authorize public content and external information sharing
Actions permitted without identification or authentication are explicitly defined, documented, and limited to designated public functions. Information shared with external parties requires owner authorization consistent with classification and sharing agreements. Only trained, designated individuals may post content to publicly accessible systems, with pre-publication review and periodic checks to ensure no nonpublic information is exposed.
unified · Context
UC-ASSET-01 — Maintain a complete inventory of systems, hardware, and software
Maintain a documented inventory of all hardware, software, systems, and services, recording owner, location, and the attributes needed for accountability and security management. Update the inventory as part of component installation, removal, and change, and reconcile it at least quarterly to correct discrepancies. Include every in-scope component so the inventory serves as the authoritative record of protected information assets for audit and compliance scoping.
unified · Context
UC-ASSET-03 — Classify, prioritize, and label information and assets
Classify information and associated assets under a documented scheme based on sensitivity, criticality, and business impact, and prioritize assets and protections accordingly. Apply labels and markings, including on physical media, that identify the classification and any distribution or handling limitations. Identify confidential information at creation or receipt and keep classifications and priorities current through periodic review.
unified · Context
UC-ASSET-04 — Control storage media through use, storage, and destruction
Restrict access to and use of removable and other storage media to authorized personnel and approved media types, and physically secure media commensurate with the classification of the data it holds. Sanitize or destroy media and equipment containing storage using approved techniques before disposal, reuse, or release from control, and verify that data can no longer be read or recovered before protections are discontinued. Retain records of media use, movement, sanitization, and destruction.
unified · Context
UC-ASSET-06 — Govern acceptable use of endpoints, off-site, and external systems
Define, communicate, and require acknowledgment of acceptable-use rules for information and associated assets. Protect user endpoint devices with enforced safeguards such as encryption, screen locking, and centralized management, and protect organizational assets used off premises against loss, theft, and observation. Permit use of or connection to external systems only under established terms and conditions consistent with the trust relationship, including restrictions on processing organizational information and on portable storage.
unified · Context
UC-AUDIT-21 — Assess control effectiveness through testing and monitoring
Management operates a monitoring program over the system of internal control that combines ongoing evaluations with separate assessments, including management self-assessments and internal audit evaluations. Controls are assessed for design and operating effectiveness on a defined frequency by assessors with a level of independence appropriate to the assessment, under documented assessment plans, and plans for security testing, training exercises, and monitoring are developed, maintained, and executed. Identified deficiencies are evaluated and communicated to those responsible for corrective action, including senior management and the board as appropriate.
unified · Context
UC-AUDIT-26 — Authorize systems and internal connections before operation
A senior accountable official formally authorizes each system to operate before production use, based on the assessed security and privacy risk to organizational operations, assets, and individuals, and reauthorizes on a defined frequency or after significant change. Internal system connections are authorized prior to establishment and documented, including interface characteristics, security and privacy requirements, and the information communicated. Authorization decisions and connection documentation are retained.
unified · Context
UC-BCDR-01 — Maintain business continuity and disaster recovery plans
Maintain documented, management-approved business continuity and disaster recovery plans that cover critical business functions and ICT services, recovery time and recovery point objectives, assigned roles, and how information security is preserved at required levels during disruption. Base the plans on a business impact analysis, distribute them to responsible personnel, and review and update them at least annually and after significant organizational or technology changes.
unified · Context
UC-BCDR-03 — Back up data and verify restorability
Back up information, software, and system images at a frequency and scope aligned to defined recovery point objectives, protect backup copies from unauthorized access and modification, and keep copies separate from the primary environment. Verify backup integrity and restorability through periodic test restores, and verify the integrity of backups before using them for restoration.
unified · Context
UC-BCDR-04 — Provide redundant and alternate processing, storage, and telecom
Implement redundancy and alternate capability sufficient to meet availability and recovery objectives: an alternate storage site for backup media, alternate processing capability sufficiently separated from the primary site to avoid shared hazards, and diverse or alternate telecommunications services with priority-of-service provisions. Ensure alternate facilities provide security controls equivalent to the primary site and can assume operations within recovery time objectives.
unified · Context
UC-BCDR-05 — Manage capacity to meet availability requirements
Determine and monitor the processing capacity and utilization of infrastructure, data, and software against current and forecast demand, and add capacity before demand exceeds defined thresholds. Protect availability of shared resources through priority-based allocation or quotas, and alert responsible personnel when capacity thresholds are breached.
unified · Context
UC-BCDR-07 — Execute recovery plans to restore systems and operations
When disruption occurs, execute the documented recovery procedures to restore systems, applications, and data to a known operational state within recovery time objectives. Select, scope, and prioritize recovery actions based on criticality and dependencies, verify the integrity of restored assets, and confirm normal operating status before returning systems to service.
unified · Context
UC-BCDR-10 — Test recovery capabilities and train contingency personnel
Test business continuity, disaster recovery, and restoration capabilities at least annually through scenario exercises, failover and restore tests, and, where required for critical systems, advanced or threat-led penetration testing. Train all personnel with contingency roles on their responsibilities upon assignment and periodically thereafter. Review test and exercise results and remediate identified gaps.
unified · Context
UC-BCDR-11 — Sustain operations via safe modes and alternate mechanisms
Design critical systems to continue operating safely when primary capabilities fail: enter a defined safe mode of operation that restricts functions when specified conditions are detected, switch to alternate communications protocols to maintain continuity, and employ alternative security mechanisms when primary security safeguards are unavailable.
unified · Context
UC-CONFIG-01 — Harden systems to approved secure configuration baselines
Establish, document, and maintain current baseline configurations and mandatory secure settings for all system components, including network security controls, aligned to accepted industry hardening standards. Configure systems for least functionality by disabling or restricting unnecessary ports, protocols, services, and functions. Monitor deployed configurations for deviations from baseline and for changes that introduce vulnerabilities, remediating drift as findings, and reassess baselines periodically and upon significant change.
unified · Context
UC-CONFIG-02 — Authorize, test, and approve changes before production
Manage changes to applications, databases, infrastructure, configurations, and procedures through a documented process in which changes are requested, analyzed for security and risk impact, authorized, tested, approved, and implemented by appropriate personnel. Require migration to production to be performed by individuals independent of development, and retain records evidencing each step. Define rollback plans and an emergency-change path with retrospective review and approval.
unified · Context
UC-CONFIG-03 — Separate environments and protect production data in testing
Separate development, test, and production environments, and enforce physical and logical access restrictions so only authorized personnel can make changes to production systems. Select, protect, and manage information used for testing, anonymizing or masking production data before use in non-production environments and removing it when testing completes.
unified · Context
UC-CONFIG-05 — Permit only authorized software installation and use
Restrict installation of software on operational systems to authorized personnel installing approved software from trusted sources, and govern user-installed software through explicit policy and technical enforcement such as allowlisting. Combine these restrictions with anti-malware controls that prevent or detect and act upon unauthorized or malicious software. Track software installation and use to comply with contract terms and license entitlements.
unified · Context
UC-CONFIG-06 — Verify authenticity and integrity of hardware and software
Assess the authenticity and integrity of hardware and software before acquisition and use, sourcing components from trusted suppliers. Verify digital signatures or equivalent integrity evidence on software, firmware, and updates before installation, and block or investigate components that fail verification.
unified · Context
UC-CONFIG-07 — Perform controlled, timely maintenance of systems and hardware
Schedule, approve, document, and review maintenance, repair, and replacement of systems and hardware in accordance with manufacturer specifications and organizational requirements, whether performed on site or off site. Sanitize equipment before off-site maintenance and verify security controls after maintenance is completed. Obtain maintenance support and spare parts within defined timeframes so hardware is maintained, replaced, or removed commensurate with risk.
unified · Context
UC-CONFIG-08 — Control maintenance tools, personnel, and remote sessions
Approve, inspect, and control maintenance tools and media brought into facilities, checking them for improper modification and malicious code. Authorize and supervise maintenance personnel against a current list of approved individuals, with escorts for those lacking required access authorizations. Require nonlocal maintenance sessions to use approved connections and strong authentication, record the session, and terminate connections when maintenance is complete.
unified · Context
UC-CONFIG-09 — Document configuration management policy, plan, and procedures
Develop, document, and implement a configuration management plan defining roles, responsibilities, processes, and procedures for identifying, managing, and protecting configuration items throughout the system development life cycle. Deploy these expectations through approved policies and actionable procedures, review them periodically, and update them when the environment or organization changes.
unified · Context
UC-CONFIG-10 — Map where information resides and how data is processed
Identify and document the location of information and the specific system components on which it is processed and stored, including designated data types such as personally identifiable information. Develop and maintain a map of system data actions covering collection, processing, storage, and transmission, and update location and mapping documentation upon change.
unified · Context
UC-CRYPTO-01 — Encrypt data at rest and in transit
Sensitive and nonpublic data at rest is rendered unreadable using strong, industry-accepted encryption, or truncation/tokenization for stored account data, with storage and retention minimized to defined business need. Data in transit is protected with strong cryptography and trusted certificates over all open, public, or external networks, rejecting fallback to insecure protocols. Transmission, movement, and removal of information, including to removable media, is restricted to authorized users and processes, and the integrity of data in both states is protected. Where encryption of nonpublic information is infeasible, compensating controls are documented, approved by the CISO, and reviewed at least annually.
unified · Context
UC-CRYPTO-02 — Use approved algorithms and validated cryptographic modules
A cryptography standard defines approved algorithms, protocols, key lengths, and certificate profiles aligned to current industry guidance, and prohibits deprecated primitives (e.g., SSL/early TLS, SHA-1, RSA below 2048 bits). Cryptographic operations protecting sensitive data use independently validated cryptographic modules operating in approved modes. The standard is reviewed at least annually against emerging cryptanalytic and post-quantum developments.
unified · Context
UC-CRYPTO-03 — Manage cryptographic keys and certificates across their lifecycle
Cryptographic keys are generated, distributed, stored, used, rotated, revoked, and destroyed under documented procedures, with keys held in HSMs or hardened key stores and access limited to authorized custodians under dual control and split knowledge where warranted. Public key certificates are issued from approved certificate authorities, inventoried, monitored for expiry, renewed before lapse, and revoked promptly on compromise. Key-management activities are logged and periodically audited.
unified · Context
UC-DATA-01 — Process personal data only under a documented lawful basis
Identify and document the lawful basis and organizational authority for each personal-data processing activity before data is collected or processed. Record the basis (e.g., consent, contract, legal obligation, legitimate interest) in the processing register and collect personal data only for those documented purposes. Review the register at least annually and whenever processing changes.
unified · Context
UC-DATA-02 — Obtain and honor consent for collection, use, and disclosure
Where consent or authorization is the basis for collecting, using, retaining, disclosing, selling, or sharing personal data, present the available choices and their consequences clearly and capture freely given, specific, informed consent before the data is collected or disclosed. Maintain auditable consent records, honor withdrawal and opt-out requests (including opt-out of sale/sharing and limits on sensitive-data use) as easily as consent was given, and use compliant authorization forms where required. Document the basis for any implied consent relied upon.
unified · Context
UC-DATA-03 — Limit personal-data use to stated purposes and minimum necessary
Identify and document the specific purposes for which personal data is processed, and restrict use and disclosure to those purposes or documented compatible ones. Apply the minimum-necessary standard so only the least data required is used, disclosed, or requested for each purpose. Obtain new authority or consent before processing for any new purpose.
unified · Context
UC-DATA-04 — Restrict processing of special categories of personal data
Inventory all processing of special categories of personal data (e.g., health, biometric, genetic, race or ethnicity, religion, sexual orientation) and prohibit such processing unless a documented legal exception or explicit consent applies. Apply heightened safeguards to this data and record the exception relied upon for each processing activity.
unified · Context
UC-DATA-05 — Provide privacy notices and transparency to data subjects
Publish and maintain privacy notices that describe, in clear and plain language, the categories of personal data collected, purposes, lawful bases, recipients, retention periods, and data-subject rights, and deliver them at or before the point of collection. Update and re-communicate notices in a timely manner when practices change, and publish any legally required registrations such as system-of-records notices. Retain dated notice versions as evidence.
unified · Context
UC-DATA-07 — Keep personal data accurate and honor correction requests
Maintain personal data that is accurate, complete, up to date, and relevant for its intended use, with periodic data-quality checks. Provide a process for individuals to request correction or amendment, execute or formally deny each request within statutory deadlines with stated reasons, and communicate corrections to third parties to whom the data was disclosed.
unified · Context
UC-DATA-09 — Retain personal and confidential data per schedule, then destroy it
Maintain an approved retention schedule for personal and confidential information tied to documented legal and business requirements, and retain data no longer than the schedule permits. When retention ends, delete or irreversibly destroy the information wherever it resides, including in external services, using methods that prevent reconstruction, and record disposal actions as evidence.
unified · Context
UC-DATA-10 — Protect physical media containing sensitive data
Store physical media holding sensitive or personal data in secured, access-controlled locations. Protect media during transport outside controlled areas using authorized personnel or couriers, accountability tracking, and encryption or locked containers. Sanitize media commensurate with its highest recorded classification before downgrading, reuse, or release, and maintain storage, transfer, and sanitization records.
unified · Context
UC-DATA-11 — Control data flows, leakage, and cross-border transfers
Enforce approved authorizations for information flows within and between systems using technical flow-control mechanisms, and deploy data-leakage-prevention measures on systems and channels that could exfiltrate sensitive data. Transfer personal data across borders only under a valid transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules, or a documented derogation), with the transfer risk assessed and the safeguard recorded.
unified · Context
UC-DATA-12 — De-identify, mask, or pseudonymize personal data
Apply masking, pseudonymization, or de-identification when full identifiers are not required, following policy and the applicable legal standard (e.g., expert determination or safe-harbor methods, limited data sets under agreement). Protect the keys and mappings that could re-identify data, and prohibit re-identification attempts.
unified · Context
UC-DATA-18 — Govern automated matching of PII under formal agreements
Enter formal agreements before participating in automated matching of personal data between organizations or systems, specifying the purpose, data elements, and verification procedures. Provide any required notice, independently verify matched information before taking adverse action against an individual, and retain agreements and verification records as evidence.
unified · Context
UC-FIN-04 — Authorize transactions with attributable approvals
Require transactions, journal entries, and master-data or configuration changes to be reviewed and approved by authorized personnel in accordance with the delegation-of-authority matrix before they are recorded or executed. Capture approvals in systems under unique authenticated user accounts with tamper-evident audit trails that irrefutably bind each approval to the individual who performed it, so that approval actions cannot be repudiated. Evidence includes the delegation-of-authority matrix, approval workflow configurations, and approval audit trails.
unified · Context
UC-GOV-07 — Hold individuals accountable for control responsibilities
Management requires all personnel to apply information security in accordance with established policies and procedures and holds individuals accountable for their internal control responsibilities. Accountability is enforced through defined expectations, documented rules of behavior acknowledged before access is granted and re-acknowledged when updated, performance measures and incentives, and disciplinary consequences for violations.
unified · Context
UC-GOV-09 — Appoint accountable security leadership (CISO)
Designate a qualified senior leader (e.g., a Chief Information Security Officer) with organization-wide responsibility, accountability, authority, and resources to develop, implement, and enforce the information security program, and designate accountable leadership roles for the risk management program. The security leader reports in writing on the program, material cybersecurity risks, and remediation plans to the board or equivalent governing body at least annually.
unified · Context
UC-GOV-11 — Allocate adequate resources and budget for security
Allocate and manage funding, personnel, and other resources commensurate with the organization's cybersecurity risk strategy, roles, responsibilities, and policies, ensuring security and privacy requirements are addressed in capital planning, budgeting, and investment decisions. Periodically evaluate resource allocation and utilization for adequacy and optimization, and adjust budgets as priorities and risks change.
unified · Context
UC-GOV-14 — Establish and maintain approved security policies and procedures
Establish, approve, publish, and maintain the organization's information-security policy suite as a governed whole: a top-level policy plus the topic-specific policies, each with an accountable owner, board/management approval, planned review cycles, and communication to relevant parties. Domain-specific policy content is governed by its own unified control; this objective owns the suite-level lifecycle (inventory, approval chain, review cadence, communication, exceptions).
unified · Context
UC-GOV-15 — Operate a management-approved information security program
Establish, implement, and maintain an organization-wide information security program, documented in a program plan approved by senior management and based on the organization's risk assessment. Define the program's scope, security objectives, protective functions (identify, protect, detect, respond, recover), supporting management processes, and coordination among organizational entities, and review and update the program plan at planned intervals and after significant change.
unified · Context
UC-GOV-16 — Select and tailor a risk-based control baseline
Select and document a baseline of security and privacy controls — including general controls over technology — responsive to assessed risks, and tailor it to the organization's environment, complexity, and risk appetite, considering an appropriate mix of preventive and detective control types and segregation of duties. Centrally identify, manage, and deploy common controls where appropriate, and document and approve the rationale for all tailoring decisions.
unified · Context
UC-GOV-17 — Establish enterprise risk management strategy and appetite
Establish, document, and communicate a leadership-approved enterprise risk management strategy, including risk management objectives agreed by stakeholders, defined risk appetite and tolerance statements, and a documented risk assessment policy with procedures and a consistent methodology for identifying, analyzing, prioritizing, and responding to risk. Ensure governance activities keep risk-taking optimized within appetite, and review and update the strategy, appetite, and policy at planned intervals.
unified · Context
UC-GOV-18 — Document and approve system security and privacy plans
Develop, approve, and maintain security and privacy plans for systems that describe each system's authorized purpose, boundary, operating context and concept of operations, requirements, and the controls in place or planned. Distribute plans to authorized personnel, protect them from unauthorized disclosure and modification, review them at defined intervals, and update them to address changes — verifying that systems continue to be used only for their intended and authorized purposes.
unified · Context
UC-GOV-19 — Maintain enterprise security and privacy architecture
Establish and maintain an enterprise architecture, including security and privacy architectures, that describes how systems, information flows, and protections align with the organization's mission and strategy and address security and privacy risks. Review and update the architecture at defined intervals and reflect it in system security plans, solution designs, and acquisition decisions.
unified · Context
UC-GOV-20 — Govern data as an asset with accountable oversight bodies
Establish data governance: policies and standards for managing data through its life cycle, and formally chartered governance bodies (e.g., a data governance body and, where required, a data integrity board) with defined membership and responsibilities. These bodies oversee data management, data quality and integrity, and the review and approval of data-sharing and matching agreements, and report on data governance at defined intervals.
unified · Context
UC-GOV-22 — Assess control effectiveness and authorize systems
Maintain a documented assessment and authorization policy with procedures, defined performance measures, and quality monitoring to regularly evaluate whether security policies, standards, and risk-management measures are implemented, complied with, and effective — including managers' reviews of compliance within their areas of responsibility. Feed assessment results into a formal, risk-based authorization process in which a senior official explicitly accepts residual risk before systems operate and at defined intervals thereafter, and track findings to closure.
unified · Context
UC-GOV-23 — Maintain contacts with authorities and special interest groups
Establish, document, and maintain contacts and communication channels with relevant authorities (e.g., regulators, supervisory bodies, law enforcement) and with special interest groups, security forums, and professional associations, defining when and by whom each contact is used, including during incidents. Review contact lists at defined intervals to keep them current, and use these channels to stay abreast of recommended practices, emerging threats, and regulatory expectations.
unified · Context
UC-GOV-25 — Operate a privacy program with accountable leadership
Establish and maintain a privacy program and program plan defining the technical and organisational measures by which the organization ensures, and is able to demonstrate, compliance with privacy requirements. Designate a qualified, appropriately independent privacy leader (a Data Protection Officer where required) with defined tasks, adequate resources, and direct reporting to the highest level of management. Disseminate privacy program information to the workforce and the public, and report on privacy posture and program effectiveness at defined intervals.
unified · Context
UC-GOV-26 — Enforce personal-data processing principles and minimization
Adopt and enforce policies and procedures requiring that personal data is processed lawfully, fairly, and transparently; collected for specified, explicit purposes; limited to what is necessary; kept accurate through defined quality-management checks and correction procedures; stored no longer than needed; and protected — with accountability demonstrable through documentation. Minimize or use de-identified personally identifiable information in testing, training, and research, applying documented techniques where full data is not required.
unified · Context
UC-GOV-27 — Manage privacy complaints and account for disclosures
Implement a process to receive, track, and resolve privacy-related complaints, concerns, and questions from individuals within defined response times, including escalation paths and feedback to complainants. Maintain an accurate accounting of disclosures of personal information — including date, nature, purpose, and recipient — retained for the required period and made available to the individuals concerned upon request.
unified · Context
UC-GOV-29 — Maintain secure acquisition, development, and maintenance policies
Establish, document, and disseminate policies and procedures governing security in system and services acquisition, in-house application development, configuration management, and system maintenance — including secure development standards, evaluation criteria for externally developed applications, and baseline configuration requirements. Review, assess, and update these policies and procedures at least annually under accountable security leadership and after significant changes.
unified · Context
UC-GOV-30 — Maintain asset, media, and physical protection policies
Establish, document, and disseminate policies and procedures for asset management, media protection, and physical and environmental protection — including maintenance of a complete asset inventory, secure handling, marking, storage, and sanitization of media, and data retention limits with secure disposal of nonpublic information no longer required for business or legal purposes. Review and update these policies and procedures at defined intervals and upon significant change.
unified · Context
UC-GOV-31 — Maintain access control, identity, and personnel security policies
Establish, document, and disseminate policies and procedures governing logical access control, identification and authentication, and personnel (human resources) security — covering authorization based on need-to-know and least privilege, credential and authenticator management, and personnel screening, transfer, and termination requirements. Communicate these policies to the workforce and review and update them at defined intervals and upon significant change.
unified · Context
UC-GOV-32 — Maintain security awareness and cyber-hygiene policies
Establish, document, and disseminate policies and procedures for security awareness, training, and basic cyber-hygiene practices applicable to all personnel, defining required content, frequency, audiences, and completion tracking. Review and update the policy and program requirements at defined intervals and in response to changes in threats and incidents.
unified · Context
UC-GOV-33 — Maintain logging, monitoring, and system integrity policies
Establish, document, and disseminate policies and procedures for audit logging and accountability and for system and information integrity, and define an organization-wide continuous monitoring strategy specifying metrics, monitoring and assessment frequencies, and how results inform risk decisions. Review and update the policies and the monitoring strategy at defined intervals and upon significant change.
unified · Context
UC-GOV-34 — Maintain business continuity and contingency planning policy
Establish, document, and disseminate contingency planning policy and procedures, identify risks arising from potential business disruptions — including to critical infrastructure and essential services — and select and develop mitigation activities (including consideration of insurance and other risk transfer) proportionate to those risks. Review and update the policy and the mitigation portfolio at defined intervals and after significant disruptions.
unified · Context
UC-GOV-35 — Maintain incident response policy and procedures
Establish, document, and disseminate an incident response policy and supporting procedures that define what constitutes a security incident, roles, responsibilities, and authorities, and requirements for detection, internal reporting, handling, escalation, and post-incident review. Review and update the policy and procedures at defined intervals and after significant incidents or exercises.
unified · Context
UC-GOV-36 — Maintain communications security and cryptography policies
Establish, document, and disseminate policies and procedures for system and communications protection, including the required use of cryptography and encryption, secured communication channels, and multi-factor and strong authentication expectations for remote and privileged access. Review and update these policies at defined intervals and as cryptographic standards and threats evolve.
unified · Context
UC-GOV-37 — Operate insider-threat and threat-awareness programs
Implement an insider threat program that includes a cross-discipline insider threat incident handling team and defined indicators, reporting channels, and response procedures, together with a threat awareness program that shares current threat information across the organization, including with leadership and security personnel. Review the effectiveness of both programs at defined intervals and adjust them to the evolving threat environment.
unified · Context
UC-HR-01 — Screen personnel commensurate with position risk
Every position is assigned a risk designation that determines its screening requirements and is reviewed as roles change. Background verification, including identity, employment and education history, and criminal or other checks as permitted by law, is completed before employment and before access to systems or sensitive information, proportional to position risk and data sensitivity. Personnel in high-risk roles are rescreened at defined intervals, and screening records are retained.
unified · Context
UC-HR-02 — Formalize security responsibilities in employment terms
Employment contracts and terms state each individual's information security responsibilities, including obligations that survive employment. Personnel sign confidentiality or non-disclosure agreements and access agreements before being granted access, and re-sign when agreements are materially updated. Position descriptions document role-specific security duties, and signed acknowledgments are retained as evidence.
unified · Context
UC-HR-03 — Secure termination and transfer of personnel
A documented separation process ensures that on termination, system access is revoked and organizational assets are recovered on a defined timeline, same-day for involuntary separations, with exit discussions reaffirming surviving confidentiality obligations and notification of relevant parties. On transfer or role change, access is re-evaluated and adjusted to the new role within a defined period, with changes logged.
unified · Context
UC-HR-04 — Enforce a formal disciplinary process for violations
A formal, communicated disciplinary process is applied to personnel who violate information security policies, providing graduated, consistent sanctions proportional to severity and intent. Violations, sanctions applied, and notifications to defined roles are documented and retained, and outcomes feed back into awareness and control improvements.
unified · Context
UC-HR-05 — Hold third-party personnel to equivalent security terms
Contracts with suppliers and external organizations whose personnel access systems or data require equivalent personnel security measures, including screening, confidentiality agreements, and defined security responsibilities, and oblige the provider to notify the organization of personnel transfers or terminations affecting access. Third-party compliance with these personnel requirements is monitored.
unified · Context
UC-IR-01 — Maintain an approved incident response plan
Maintain a written incident response plan that defines the mission and scope of the response capability, incident definitions and severity structure, roles, responsibilities, and communication paths, and how the capability coordinates with business continuity and third parties. Have the plan approved by designated management, distribute it to named response personnel, and review and update it on a defined frequency and after significant incidents or organizational changes, protecting it from unauthorized disclosure and modification.
unified · Context
UC-IR-02 — Train responders and test the incident response capability
Provide role-based incident response training to users, responders, and leadership within a defined period of assuming the role, when systems or the plan change materially, and at least annually thereafter. Test the incident response capability on a defined schedule using exercises such as tabletop simulations, document results and lessons, and feed identified gaps back into the plan and the training program.
unified · Context
UC-IR-03 — Provide channels to report events and obtain response help
Operate well-known channels — such as a monitored mailbox, hotline, or service portal — through which all personnel can and are directed to report observed or suspected security events as quickly as possible. Provide an incident response support resource, integral to the response capability, that offers advice and assistance to users on reporting and on handling suspected events. Acknowledge every report and route it into triage.
unified · Context
UC-IR-06 — Respond to, contain, and eradicate declared incidents
On declaration of an incident, execute the incident response plan in coordination with internal teams and relevant third parties such as providers, law enforcement, and insurers. Contain the incident using predefined strategies for its category, eradicate the cause by removing malicious artifacts and closing exploited weaknesses, and coordinate handling with contingency and recovery activities through to resolution. Communicate response status as the plan requires and document all response actions taken, feeding lessons into response procedures.
unified · Context
UC-IR-07 — Investigate incidents and preserve evidence and records
Track and document every incident from declaration to closure in a system of record covering status, actions performed, decisions, and timeline. Collect incident data and evidence using documented procedures that preserve integrity, provenance, and chain of custody so evidence remains suitable for disciplinary and legal proceedings, and record investigation actions as they are performed. Perform analysis, including root-cause analysis, to establish what took place and why, and record the conclusions.
unified · Context
UC-IR-08 — Notify authorities and affected parties within deadlines
Maintain a notification matrix of internal stakeholders, regulators, and other external parties with triggers, deadlines, content requirements, and approved communication owners. Require personnel to report suspected incidents to the response capability within defined timeframes, notify authorities and other required external bodies within their statutory windows, and share incident information with designated internal and external stakeholders as the communications plan directs. Notify affected individuals when thresholds are met — for high-risk personal-data breaches, communicate without undue delay in clear and plain language with mitigation advice; for regulated categories of data, notify individuals, media, and regulators within the mandated statutory windows when applicable thresholds are reached, honoring notification duties owed to partner organizations. Retain evidence of every notification's timing, audience, and content.
unified · Context
UC-IR-11 — Respond to information spillage with defined procedures
Maintain and execute a documented procedure for responding to information spillage — sensitive or regulated information landing on systems not authorized to hold it. On discovery, identify the information and the extent of contamination, alert designated personnel without amplifying exposure, isolate and eradicate the spilled information from affected systems and backups, and assess any obligations triggered by the exposure. Provide procedures and training for personnel exposed to spilled information and document each spill response.
unified · Context
UC-LOG-01 — Log security-relevant events across all systems
Enable audit logging on all systems, applications, and network components, generating records for a defined catalog of security-relevant event types — at minimum authentication, all access to sensitive or regulated data (such as cardholder data), privileged actions, account and configuration changes, and security-tool events. Review and update the event catalog periodically with system owners, ensure logging is enabled by default on newly deployed components, and verify logging coverage on a defined cadence.
unified · Context
UC-LOG-02 — Record complete audit content with synchronized clocks
Capture audit records whose content establishes what happened, when it happened, where it occurred, the source, the outcome, and the identity of associated users or subjects, with centrally managed additional fields where investigations require them. Synchronize clocks on all logging systems to an approved authoritative time source, record timestamps in a consistent format mappable to UTC with defined granularity, and monitor for and correct clock drift.
unified · Context
UC-LOG-03 — Protect audit logs and retain them for required periods
Protect audit information and logging tools from unauthorized access, modification, and deletion: restrict access to a need-to-know subset of personnel, forward records to storage that users of the source system cannot alter, and alert on tampering attempts. Allocate log storage capacity consistent with retention requirements, and alert designated personnel and take defined actions when logging fails or capacity thresholds are reached. Retain audit records per a documented schedule that satisfies the longest applicable legal and regulatory period — for example five years where transaction-reconstruction rules apply — with recent security logs readily available for analysis.
unified · Context
UC-LOG-04 — Continuously monitor systems for anomalous activity
Operate continuous monitoring under a documented strategy that defines what is monitored, the metrics, and the frequencies — including ongoing assessment of security-control effectiveness — and report security status to defined roles on a defined cadence. Deploy monitoring across hosts, networks, and applications, at the perimeter and interior, to detect attacks, indicators of compromise, unauthorized connections, and anomalous behaviour indicative of malicious acts, natural disasters, or errors. Analyze flagged anomalies promptly to determine whether they represent security events requiring further evaluation.
unified · Context
UC-LOG-05 — Correlate and analyze events centrally with threat intel
Aggregate logs and alerts into a central analysis capability (such as a SIEM) that correlates information from multiple internal and external sources and enriches it with cyber threat intelligence and contextual information. Review and analyze collected records on a defined cadence for indications of inappropriate or unusual activity, using record-reduction and on-demand report generation that does not alter the original records. Route findings and adverse-event information to authorized staff and tools, and communicate monitoring responsibilities and results internally so accountable parties can act.
unified · Context
UC-LOG-07 — Monitor user sessions and personnel activity
Monitor user and administrator activity for signs of misuse: capture and review session activity for defined high-risk circumstances such as privileged or remote sessions, with legal review and any required disclosure to users, and monitor personnel technology usage against acceptable-use expectations to surface potentially adverse events. Restrict access to captured session data to authorized reviewers and involve HR and legal counsel in handling findings.
unified · Context
UC-LOG-09 — Monitor providers and exchange audit data across organizations
Define monitoring requirements for external service providers and monitor their activities, service status, and security-relevant events against contractual obligations, reviewing provider-supplied logs and reports on a defined cadence. Where audit trails cross organizational boundaries, agree methods for coordinating, exchanging, and protecting audit information with the external parties and preserve the identity context needed to trace cross-organizational actions.
unified · Context
UC-LOG-11 — Monitor external sources for unauthorized information disclosure
Monitor open-source channels — public websites, code repositories, paste and file-sharing sites, and dark-web sources — on a defined frequency for evidence that organizational information has been improperly disclosed. On discovery, alert designated personnel, initiate takedown or mitigation, and feed the finding into security-event evaluation.
unified · Context
UC-NET-01 — Segment networks and defend the external boundary
Segment networks into zones based on trust level, sensitivity, and function, and mediate all traffic at managed interfaces (firewalls, gateways, proxies) with deny-by-default rules at the external boundary and key internal boundaries. Monitor and control communications crossing each boundary to protect against threats originating outside the system boundary, and review segmentation and rule sets periodically.
unified · Context
UC-NET-02 — Authorize and secure remote, wireless, and mobile access
Establish usage restrictions, configuration and connection requirements, and explicit authorization for each type of remote access, wireless access, and organization-controlled mobile device before connection is permitted. Protect these connections with mutual authentication, encryption, and wireless link-level protections commensurate with the signal exposure and threat environment, and monitor for unauthorized access points and connections.
unified · Context
UC-NET-03 — Provide trusted channels and control session lifecycle
Provide trusted, mutually authenticated communication paths for security-relevant interactions, and protect the authenticity and integrity of communication sessions to prevent hijacking, insertion, and replay. Terminate network connections at the end of a session or after a defined period of inactivity, and use separate out-of-band channels for delivering sensitive items such as credentials and keys.
unified · Context
UC-NET-04 — Isolate system, user, and security functions
Separate user functionality, including user-interface services, from system-management functionality, and isolate security functions from non-security functions using partitioning, virtualization, or separate physical or logical components. Partition the system so components of differing sensitivity reside in separate domains, limiting the blast radius of a compromise.
unified · Context
UC-NET-05 — Prevent leakage via shared resources and covert channels
Prevent unauthorized or unintended information transfer through shared system resources by clearing, sanitizing, or isolating resources between users and processes. Analyze the system for covert storage and timing channels, estimate their bandwidth, and reduce or eliminate identified channels that exceed acceptable thresholds.
unified · Context
UC-NET-06 — Enforce separation with hardware and software mechanisms
Employ hardware-enforced and software-enforced separation mechanisms to isolate critical security functions and enforce policy between execution domains. Use hardware-based protections such as write-protected or read-only memory, and load and execute key programs from hardware-enforced non-modifiable media so critical code cannot be altered at runtime.
unified · Context
UC-NET-07 — Secure name resolution and time services
Provide authoritative name-resolution service with origin authentication and integrity verification (e.g., DNSSEC), and perform data-origin authentication and integrity validation in recursive or caching resolvers. Architect name-resolution services to be fault tolerant and to enforce internal and external role separation, and synchronize system clocks to authoritative time sources so events can be correlated reliably.
unified · Context
UC-NET-08 — Maintain communications availability under attack and failure
Protect network services against denial-of-service events through capacity management, rate limiting, filtering, or upstream DoS-mitigation services. Ensure components fail to a known, secure state while preserving essential state information, and maintain alternate communications paths so operations can continue if primary channels degrade or fail.
unified · Context
UC-NET-09 — Reduce attack surface through resilient architecture
Architect infrastructure to resist attack and localize failures: deploy minimal-functionality (thin) nodes where feasible, employ heterogeneity in key technologies to avoid common-mode compromise, and distribute processing and storage across multiple physical locations or components. Review these architecture decisions against current threats periodically.
unified · Context
UC-NET-10 — Deploy deception and dynamic detection capabilities
Deploy decoy components (honeypots or honeynets) and honeyclient capabilities to attract, detect, and analyze malicious activity and externally hosted malicious code without exposing production assets. Detonate suspicious files, URLs, and code in isolated sandbox environments before delivery to users, and relocate or reposition detection sensors as threat conditions change.
unified · Context
UC-NET-11 — Conceal operational information from adversaries
Operate an operations-security (OPSEC) process that identifies critical operational information, analyzes how adversaries could collect and exploit it, and applies countermeasures to deny that collection across the system lifecycle. For designated systems, employ concealment and misdirection techniques, such as hiding system details or randomizing observable behavior, to increase attacker uncertainty and cost.
unified · Context
UC-NET-12 — Restrict communication-capable devices, ports, and sensors
Prohibit remote activation of collaborative computing devices (cameras, microphones, shared whiteboards) except where explicitly authorized, and give people present an explicit indication of use. Physically or logically disable unneeded connection ports and input/output devices, and restrict on-board sensor capability and the use of sensor-collected data. Define, authorize, and enforce documented usage restrictions for components subject to them.
unified · Context
UC-NET-13 — Control mobile code and web content
Define acceptable and unacceptable mobile-code technologies, and authorize, monitor, and control mobile code so unauthorized active content cannot execute in browsers, documents, or email. Filter access to external websites by category and reputation to reduce exposure to malicious content, and log enforcement actions.
unified · Context
UC-NET-14 — Enforce policy on cross-domain information exchange
Associate security and privacy attributes (labels) with information exchanged between systems and preserve them in transmission so receiving systems can enforce handling policy. Enforce mandatory information-exchange policy at cross-domain interconnection points so only authorized data types and flow directions are permitted between security domains.
unified · Context
UC-PHYS-01 — Restrict physical access to facilities and secure areas
Define physical security perimeters and secure areas, and authorize, issue, and periodically review physical access credentials so only authorized personnel can enter facilities, offices, and sensitive locations such as data centers and backup media storage. Enforce entry controls at every access point, escort and log visitors, and apply defined rules for working in secure areas. Maintain physical access audit logs for entries and exits at controlled access points, and secure, inventory, and rotate physical access devices such as keys, combinations, and badges when compromised or when personnel change. Revoke or adjust physical access promptly upon termination or role change.
unified · Context
UC-PHYS-02 — Monitor physical access and retain visitor and entry records
Continuously monitor physical access to facilities and sensitive areas using surveillance, intrusion detection, and review of physical access logs. Maintain visitor access records including identity, date, time, and purpose of entry. Review monitoring output and access records on a defined cadence, retain them for the required period, and investigate anomalies and apparent violations.
unified · Context
UC-PHYS-03 — Protect facilities against fire, water, and environmental hazards
Design and equip facilities to protect technology assets from fire, water, temperature, humidity, and other physical and environmental threats. Deploy and independently maintain fire detection and suppression, water damage detection with accessible shutoff valves, and environmental monitoring and control at required levels. Configure alarms to notify responsible personnel automatically when protective systems activate or parameters go out of range.
unified · Context
UC-PHYS-04 — Site facilities and equipment to minimize hazards and exposure
Position facilities and system components to minimize damage from physical and environmental hazards and to reduce opportunities for unauthorized access and observation. Consider physical and environmental risk when selecting facility locations, and apply compensating safeguards for equipment sited in higher-risk locations.
unified · Context
UC-PHYS-05 — Provide emergency power, lighting, and resilient utilities
Protect supporting utilities such as power, HVAC, and telecommunications from failure and disruption, with inspection and maintenance on a defined schedule. Provide uninterruptible power and generator capacity sized to enable orderly shutdown or continued operation of critical systems, and automatic emergency lighting covering evacuation routes. Provide accessible, protected emergency shutoff capability to cut power to systems safely in an emergency.
unified · Context
UC-PHYS-06 — Protect power and communications cabling from damage and taps
Protect power equipment and power and telecommunications cabling from interception, interference, and damage, using measures such as protected conduits, separation of power and communications lines, and controlled access to patch panels, wiring closets, and transmission infrastructure. Periodically inspect cabling and access points for tampering or unauthorized devices.
unified · Context
UC-PHYS-07 — Shield systems from electromagnetic leakage and pulse threats
Prevent information leakage through electromagnetic signal emanations by shielding, separation, or placement of components that handle sensitive information. Employ protective measures such as shielding, surge protection, and component placement to limit damage to designated systems from electromagnetic pulse events.
unified · Context
UC-PHYS-09 — Prevent information exposure at desks, screens, and outputs
Enforce clear desk and clear screen rules so sensitive information is not left visible on unattended workspaces, displays, or printed materials. Restrict physical access to printers, scanners, and other output devices so only authorized individuals can retrieve output, and require prompt collection of printed material.
unified · Context
UC-PHYS-10 — Control and track asset delivery, removal, and movement
Authorize, monitor, and record system components and other assets entering or leaving facilities, and isolate delivery and loading areas from sensitive spaces. Track and monitor the location of designated assets while outside controlled areas, and investigate unauthorized removal or unexpected movement.
unified · Context
UC-PHYS-11 — Secure alternate work sites
Determine which alternate work sites are permitted and define the security controls required when personnel work from them, including physical protection of equipment and information. Assess the effectiveness of those controls and provide workers a means to report security incidents and problems from alternate sites.
unified · Context
UC-PHYS-12 — Mark hardware components with handling designations
Mark system hardware components with designations, such as impact level or classification, that indicate their handling, distribution, and protection requirements. Keep markings legible, durable, and consistent with the organization's classification scheme so personnel apply the correct physical safeguards.
unified · Context
UC-RISK-03 — Define risk appetite, tolerance, and risk assessment criteria
The organization documents its risk framing: risk appetite and tolerance statements, assumptions, constraints, priorities, and the scope and context within which risk is managed. A standardized, structured methodology for calculating, documenting, categorizing, and prioritizing risks is defined, approved, communicated, and maintained. Risk criteria and appetite statements are reviewed periodically and after significant organizational change.
unified · Context
UC-RISK-04 — Define objectives and business context for risk assessment
The organization specifies business objectives with sufficient clarity to enable the identification and assessment of risks relating to those objectives. Mission-essential and business processes are defined, including their information protection needs, and serve as the basis for risk assessment scoping. Objective and process definitions are documented, approved, and revisited when strategy or operations change.
unified · Context
UC-RISK-06 — Perform periodic enterprise risk assessments
The organization performs an enterprise-wide risk assessment at least annually and upon significant change, identifying and analyzing risks to the achievement of objectives, including cybersecurity, privacy, and financial reporting risks. Assessments follow the documented methodology, address the design of the control environment and evolving threats and technologies, and are approved by management. Assessment reports, methodology references, and approvals are retained as evidence.
unified · Context
UC-RISK-09 — Select, plan, and implement risk treatments
For each risk exceeding tolerance, a response (accept, avoid, mitigate, or share/transfer) is selected consistent with the organization's strategic risk response direction. Treatment plans with owners, actions, and timelines are formulated, approved, implemented, and tracked to completion, and residual risk is re-evaluated against tolerance. Response decisions and treatment status are communicated to stakeholders.
unified · Context
UC-RISK-14 — Track deficiencies to closure with remediation action plans
Control deficiencies and assessment findings are evaluated and communicated in a timely manner to the parties responsible for corrective action, including senior management and the board as appropriate. A remediation action plan (or equivalent log) documents planned corrective actions, owners, required resources, and completion dates for each finding. Plans are maintained, kept current, and tracked through closure.
unified · Context
UC-RISK-16 — Conduct privacy impact assessments for high-risk processing
Privacy / data protection impact assessments are conducted before initiating processing likely to result in high risk to individuals, covering a systematic description of processing, necessity and proportionality analysis, risk assessment, and mitigation measures, with advice from the designated privacy officer and consultation with the competent regulator where required. Assessments are documented, approved, reviewed when processing changes, and retained.
unified · Context
UC-RISK-17 — Operate threat intelligence and threat hunting
Information relating to threats is collected from internal and external sources and analyzed to produce actionable strategic, tactical, and operational threat intelligence that informs risk assessments and defensive measures. A threat hunting capability proactively searches organizational systems for indicators of compromise that evade existing detection controls. Intelligence products and hunt reports are produced on a defined cadence and drive response actions.
unified · Context
UC-RISK-18 — Categorize systems and components by impact and criticality
Systems and the information they process, store, and transmit are categorized based on the potential impact of a loss of confidentiality, integrity, and availability, with categorization decisions documented and approved by accountable officials. Criticality analysis identifies critical system components, functions, and dependencies so protection and resilience investments are prioritized accordingly.
unified · Context
UC-SDLC-01 — Follow a secure development lifecycle with approval gates
Define and follow a documented development lifecycle with security integrated into every phase from requirements through design, build, test, and release, including defined security activities, secure development standards and tooling, and management approval gates. Ensure new systems and significant changes are designed, developed, tested, and approved in accordance with management's specifications before migration to production. Monitor adherence to and performance of the secure development process.
unified · Context
UC-SDLC-02 — Plan and resource development programs and projects
Manage development initiatives as governed programs and projects with defined scope, stakeholders, benefits, milestones, and risk management through delivery. Identify information security requirements during planning and allocate the resources and budget needed to fulfill them as an explicit line item.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
unified · Context
UC-SDLC-05 — Enforce secure coding and input validation standards
Establish and enforce secure coding standards for in-house and reused code, covering common weakness classes and secure use of components. Validate all information inputs for syntax, semantics, type, length, and range at trust boundaries, rejecting or safely encoding unsafe input. Verify adherence through code review and static analysis before release.
unified · Context
UC-SDLC-06 — Maintain configuration control over systems and code
Maintain configuration management over solution components throughout development and operation: identify configuration items, establish and protect baselines for code, dependencies, and build settings, record and verify configuration information, and review deviations. Require developers to track the integrity of changes to configuration items, implement only approved changes, and track and resolve resulting security flaws.
unified · Context
UC-SDLC-08 — Maintain current system documentation and knowledge
Obtain, produce, and maintain current administrator and user documentation for systems, covering secure configuration, use, and maintenance, and protect and distribute it to authorized roles. Keep development and operational knowledge validated, current, and available to the personnel who need it.
unified · Context
UC-SDLC-09 — Prepare and train users for new and changed systems
Plan and manage the organizational side of new and changed systems: communicate impacts, prepare business and IT stakeholders, and sustain adoption after go-live. Require system developers to provide role-appropriate training and training materials for administrators, users, and security personnel before deployment.
unified · Context
UC-SDLC-10 — Oversee outsourced development and vet developers
Direct, monitor, and review outsourced and third-party development: contractually define secure-development requirements, intellectual property ownership, and audit rights, review deliverables against requirements, and obtain evidence of security testing. Screen developers of critical systems against defined criteria before granting them access to development environments.
unified · Context
UC-SDLC-11 — Apply specialized development to critical components
Identify components critical to security or mission and, where commercial items cannot meet requirements, use customized or specialized development, such as reimplementation, custom variants, or context-specific augmentation, to reduce supply-chain and assurance risk. Document the rationale and assurance evidence for each specialized component.
unified · Context
UC-SDLC-12 — Manage solution assets and retire unsupported components
Manage application and infrastructure assets through their life cycle: maintain an accurate record of solution assets, ownership, and licensing, and optimize their use and cost. Identify system components approaching end of support and replace or upgrade them, or apply documented compensating controls with explicit risk acceptance, before support lapses.
unified · Context
UC-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
unified · Context
UC-TPRM-02 — Perform risk-based due diligence before engaging vendors
Before entering a formal relationship, perform security due diligence on prospective vendors and business partners proportionate to their criticality, evaluating security posture, financial and operational risk, and supply-chain exposure, and document the acceptance decision. Use acquisition strategies, sourcing methods, and selection criteria designed to reduce supply-chain risk before contract award.
unified · Context
UC-TPRM-03 — Bind vendors to security and privacy terms by contract
Include binding security and privacy requirements in contracts and agreements with vendors, service providers, and processors before access, service delivery, or data exchange begins: required security controls, confidentiality, breach notification, audit rights, subcontractor terms, and data handling, return, and deletion obligations. Document and authorize each information exchange or system interconnection under an appropriate agreement, and review agreements periodically. Ensure agreements satisfy the contractual clause requirements mandated by applicable privacy and security regulations for the data and services involved.
unified · Context
UC-TPRM-04 — Monitor vendor performance, services, and risk
Continuously monitor third-party performance, service delivery, and security posture against contractual and risk requirements throughout the relationship. Conduct periodic reassessments and reviews, such as questionnaires, assurance reports, and audits, at a frequency based on criticality, and manage changes to supplier services. Record, prioritize, and track identified vendor risks through response and remediation.
unified · Context
UC-TPRM-05 — Include suppliers in incident notification and response
Establish agreements or contractual provisions requiring suppliers to notify the organization of security incidents and supply-chain compromises within defined timeframes. Include relevant suppliers and third parties in incident-response planning, exercises, response, and recovery activities, with coordination roles defined in advance.
unified · Context
UC-TPRM-06 — Manage secure termination and disposal at relationship end
Include termination and post-relationship provisions in supplier agreements and supply-chain risk plans: return or verified destruction of data, revocation of access and credentials, service transition, and retention of required evidence. Dispose of data, documentation, tools, and system components securely at end of life or end of relationship using defined techniques, and record each disposal.
unified · Context
UC-TPRM-07 — Verify component authenticity, provenance, and integrity
Document and maintain the provenance of critical systems, components, and data through the supply chain, for example with bills of materials and chain-of-custody records. Apply anti-tamper and anti-counterfeit measures: tamper-resistant and tamper-evident packaging and design, inspection of systems and components at receipt and on indication of tampering, and verification of component authenticity with training and reporting of suspected counterfeits.
unified · Context
UC-TPRM-08 — Govern security of external and cloud service use
Define and enforce processes for acquiring, using, managing, and exiting external system services and cloud services in line with the organization's information security requirements. Require external providers to comply with those requirements, define oversight roles and responsibilities on both sides, agree service and exit terms, and monitor provider compliance on an ongoing basis.
unified · Context
UC-TPRM-09 — Protect supply chain information through OPSEC
Apply operations security safeguards to supply-chain activities: identify sensitive information about suppliers, shipments, configurations, and delivery schedules, protect it from collection by adversaries, and limit its disclosure to parties with a validated need to know.
unified · Context
UC-TRAIN-01 — Deliver security awareness training to all personnel
Provide security and privacy awareness training to all personnel as part of onboarding, at least annually thereafter, and when threats, policies, or systems change materially. Include practical exercises reflecting current threats, such as phishing simulations and social-engineering awareness, and update content based on lessons learned and emerging risks. Require timely completion as a condition of continued system access.
unified · Context
UC-TRAIN-02 — Train personnel with specialized security roles and duties
Identify roles with significant security, privacy, or elevated-risk responsibilities (e.g., administrators, developers, incident responders, senior leaders) and provide role-based training before access or duties are granted, when systems or duties change, and at least annually. Maintain a qualified security and privacy workforce through defined competencies, development plans, and recruitment and retention practices for security staff.
unified · Context
UC-TRAIN-03 — Record training completion and measure effectiveness
Document and retain individual awareness and role-based training activities, including completion dates and content versions, for the defined retention period. Monitor completion against the assigned population and follow up on non-completion, and collect feedback and assessment results to evaluate and improve training content and delivery.
unified · Context
UC-VULN-01 — Scan for vulnerabilities and track advisories on a defined cadence
Run authenticated vulnerability scans across all in-scope systems and applications on a defined cadence — at least quarterly and after significant changes — using tools whose vulnerability feeds are kept current. Subscribe to security advisories and directives from authoritative sources, assess their applicability, and disseminate them to system owners with required actions and completion dates. Validate and record every finding in a central register with severity ratings, and track findings to closure within severity-based timeframes. Share scan results and advisory status with designated security and management roles.
unified · Context
UC-VULN-02 — Test security through independent penetration exercises
Commission penetration tests of systems, applications, and networks at least annually and after material changes, performed by qualified testers independent of the target's operation and governed by documented rules of engagement. Include both internal and external testing perspectives, validate the exploitability of identified weaknesses, and report results to accountable management. Track corrective actions from each exercise to verified closure, and use the results as a separate evaluation of whether security controls are present and functioning.
unified · Context
UC-VULN-03 — Remediate identified flaws within defined timeframes
Identify, evaluate, and install security-relevant software and firmware updates within documented, risk-based timeframes (for example, critical flaws within 15 days and high-severity within 30). Test patches for effectiveness and side effects before production deployment, use central patch-management tooling to measure coverage, and verify remediation by rescan or configuration check. Document time-bound compensating measures or formal risk acceptance for any flaw that cannot be corrected on schedule.
unified · Context
UC-VULN-04 — Test software security during development and acceptance
Require developers and project teams to perform security testing throughout development and at acceptance, including a documented test plan, static and dynamic analysis appropriate to the technology, and retained evidence of test execution and results. Define security acceptance criteria for new systems and major upgrades, and remediate weaknesses found before release into production.
unified · Context
UC-VULN-05 — Block malware, spam, and phishing across all systems
Deploy centrally managed anti-malware protection on all system components commonly affected by malicious software, with real-time and periodic scanning, automatic signature and engine updates, and tamper protection so users cannot disable or alter it. Quarantine or block detected code, alert responders, and log all detections; periodically re-evaluate components deemed not commonly affected. Filter email and web channels for spam and phishing at entry and exit points, and support the technical controls with user awareness on malware and phishing.
unified · Context
UC-VULN-06 — Verify software, firmware, and information integrity
Employ integrity-verification mechanisms — file-integrity monitoring, cryptographic hash or signature validation, and secure or measured boot where supported — to detect unauthorized changes to software, firmware, and critical information, alerting designated personnel on detection. Verify the correct operation of security and privacy functions at startup, on demand, and on a defined schedule, and act on failures or anomalies. Continuously monitor computing hardware, software, and runtime environments so unexpected changes surface as potentially adverse events for analysis.
unified · Context
UC-VULN-07 — Harden runtime error handling, output filtering, and memory
Build and configure software so that failures and outputs cannot be weaponized: handle errors gracefully, generating only the minimum information needed for correction and revealing no sensitive data in messages or logs. Validate and filter information output from applications so it matches expected content and format before release to users or downstream systems. Enable hardware- and OS-level memory protections such as data-execution prevention and address-space layout randomization on all supporting systems.
unified · Context
UC-VULN-08 — Engineer systems to fail predictably and safely
Determine mean time to failure for components whose failure could compromise security or availability, and replace or refresh them within predicted tolerances before failure occurs. Define and implement fail-safe procedures so that on detected failure conditions systems enter a known safe state — preserving security protections, alerting designated personnel, and preventing unsafe continuation of operations.
unified · Context
UC-VULN-09 — Employ non-persistence and information-resilience techniques
Reduce the attack surface available to persistent adversaries by provisioning selected components and services non-persistently and refreshing them from known-good, trusted sources at defined intervals or on demand. Refresh designated information at defined frequencies to purge stale or potentially corrupted data, source critical information from diverse suppliers or paths, and fragment designated high-value information across separate systems so no single compromise exposes or destroys it.
unified · Context
UC-VULN-11 — Embed taint mechanisms to detect data exfiltration
Embed covert taint mechanisms — such as beacon files, honeytokens, or watermarked records — into organizational systems and datasets so that exfiltration, improper modification, or unauthorized use of data can be detected. Monitor for taint activations, alert the security team when they fire, and periodically test that the mechanisms remain functional.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
Fraud & Forensic Investigation Engagement
Fraud & Forensic Investigation Engagement as a decision-aware workflow. It runs on a dedicated Audit item (audit_type: investigation) created for this allegation at intake — the confidential case record — with the workflow instance attached to that item and its visibility restricted to the named investigation team. In scope: one specific fraud allegation, worked predication-gated and confidentially from intake through evidence preservation, forensic procedures, interviews, loss quantification, and audit-committee reporting; the named deliverables are the chain-of-custody register, the findings memorandum with its loss-quantification schedule, and the privilege-marked audit-committee fraud report. Out of scope: the enterprise fraud risk profile (owned by Fraud Risk Assessment & Anti-Override Control Review, which receives scheme intelligence from this case rather than being rerun here) and any unrelated conduct discovered in passing (which gets its own intake record). It consumes the hotline intake package from Control Responsibility Communications & Ethics Hotline when so routed, and hands each control breakdown off as an Issue item — control-gap findings to Finding Remediation & Action-Plan Monitoring and ICFR-affecting deficiencies to SOX Deficiency Remediation — rather than duplicating that work.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
ITGC Change & Provisioning Testing
Runs ON a control item (a change-management or access-provisioning ITGC). Validates the change and provisioning populations for the period, draws reproducible samples, tests each sampled ticket against the control attributes (approval before migration, segregation of developer and migrator, approval before access, access matches the requested profile), records design and operating conclusions on the control, and raises every exception as an issue.
workflow · Context
Finding Remediation & Action-Plan Monitoring
Finding Remediation & Action-Plan Monitoring runs on the EXISTING parent Audit item — the issued engagement whose report findings are being followed up — enriching that Audit and its linked findings rather than creating a new engagement; the workflow instance attaches to that Audit item, and each report finding is an Issue item linked to it. It tracks issued-report findings and their agreed management actions from registration through evidence validation, closure, extension, risk acceptance, escalation, and committee reporting, and produces a verified disposition register and a signed final evidence-and-decision package. In scope: all open findings from the engagement plus any prior-cycle findings still open against the same auditee. Out of scope: re-performing engagement fieldwork and re-wording report findings (both belong to the upstream Audit Report Drafting workflow) and assembling the board pack (the downstream Quarterly Board & Audit-Committee GRC Reporting workflow consumes this cycle's outputs). It consumes the issued final report and findings register handed off from Audit Report Drafting and hands its verified outputs to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Third-Party Vendor Assurance Engagement
Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.
workflow · Context
Continuous Controls Monitoring (ISCM) Cycle
Run the continuous controls monitoring (ISCM) cycle: pull the current-period control metrics and score them against thresholds, triage degraded and failed controls, update the POA&M, report control health to governance, recalibrate the monitoring strategy, then classify the disposition and prepare, hand off, and archive the cycle package. Each interval runs as one workflow instance attached to the existing Process item that represents the ISCM / continuous-controls-monitoring program (process_type = security_process) — enrich that program record every cycle, never create a duplicate. The monitored control set is the existing Control items (Control.frequency doubles as the monitoring cadence, Control.control_owner as the accountable owner) and the POA&M is the existing Issue register (issue_type = deficiency, source = self_assessment); metric definitions and pass/degraded/fail threshold bands have no native field, so they live in the ISCM strategy document carried on the anchor Process item. The cycle produces the control-health scorecard, the reconciled POA&M, the control-health / security-status report, and the recalibrated ISCM strategy. In scope: the recurring NIST 800-137 monitoring loop — metric collection, threshold comparison, triage, POA&M maintenance, security-status reporting, and monitoring-strategy tuning for the controls under continuous monitoring. Out of scope: formal security control assessment and driving gap remediation to closure, which is owned by the downstream Security Control Assessment & POA&M Remediation workflow that consumes this cycle's handoff package. No upstream workflow feeds this one; it is triggered by the arrival of the monitoring interval.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Vendor SOC 1/SOC 2 Report Review & CUEC Mapping
Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.
workflow · Context
User Access Review & Recertification
Runs on the existing Control item for UC-ACCESS-02 (user access review) — with UC-ACCESS-03 linked by item relationship — enriching that Control, never creating a duplicate; each quarterly or event-triggered cycle is a workflow instance attached to it, so archived instances accumulate as the de-facto control execution log. A decision-aware workflow covering entitlement extraction, manager certification, revocation, and independent verification. Consumes at start the prior cycle's scope-change carry-forward Issues and prior signed report (both attached to the same Control) plus the period's source-of-record entitlement extracts and period-end HR roster. Produces a signed, audit-ready recertification evidence package and control-owner report as the named deliverable. In scope: SOX-significant applications, systems holding data classified Confidential or above, identity infrastructure (directory, SSO, PAM), and privileged-reach platforms, across all account populations (standard, privileged, service, shared, emergency break-glass, third-party); triggered on scheduled cadence or by event (post-incident, auditor request). Out of scope: lifecycle provisioning and the privileged-access model itself — systemic findings hand off to the Joiner-Mover-Leaver Access Lifecycle (lifecycle gaps) and Privileged Access & Authorization Model Management (privileged-model findings) workflows.
workflow · Context
Vulnerability & Patch Management Cycle
Recurring vulnerability & patch management lifecycle covering NIST SP 800-53 RA-5 (vulnerability scanning) and SI-2 (flaw remediation) and NIST CSF 2.0 ID.RA and PR.PS. Each cycle runs as one recurring instance anchored to the EXISTING vulnerability & patch management Control item (a Control with domains = vulnerability_patch_management — e.g. the UC-VULN-01 scanning control, control_owner = cycle owner); the instance enriches that Control's evidence trail rather than creating a new subject, and the instance itself is the cycle record. In scope: authenticated scanning of the confirmed asset inventory, severity-based triage against the SLA matrix, standard and emergency remediation, rescan verification, time-bound risk acceptance of residuals, metrics reporting, and cycle closure. Named deliverables: the deduplicated, enriched finding register (one vulnerability_scan Issue per finding, linked to the Control), rescan closure evidence, time-bound compensating-control-backed risk-acceptance exceptions (policy_exception Issues), and the cycle KPI & trend report. Consumed as inputs, not produced: the authoritative asset inventory / CMDB and the enterprise change-approval policy (a Policy item). The workflow is self-triggered by its own scheduled scan window (or an actively-exploited advisory) with no upstream or downstream workflow — its carry-forward package feeds the next iteration of this same cycle at intake.
workflow · Context
Business Continuity & DR Test Exercise
Run one operating cycle of an existing business continuity / disaster recovery plan-testing Control (the BC/DR test control this instance attaches to, UC-BCDR-04 "tests"): plan, execute, and evaluate a BC/DR exercise against the RTO and RPO objectives, then fold the resulting gaps back into the BC and DR plans as versioned redlines — a decision-aware workflow. It consumes as declared inputs the in-force BC and DR plans (existing Policy items), the business impact analysis (BIA), and prior after-action reports; it creates an Audit item (audit_type=operational) as the definitive exercise record, and produces named deliverables: an approved exercise package, an actual-versus-target RTO/RPO scorecard, remediation findings (Issue items), and a signed-off after-action report with an indexed evidence package. In scope: scoping, running, and evaluating one scheduled or triggered BC/DR exercise for the selected in-scope systems and business services, and folding resulting gaps back into the BC and DR plans. Out of scope: real incident response, and recovery-objective (RTO or RPO) changes to systems outside the agreed exercise scope. Standalone: no upstream or downstream workflow is required; any cross-workflow linkage — for example a related incident-response or BIA-maintenance workflow — is expressed as a declared input, not a predecessor.
workflow · Context
Security Awareness Training Campaign
Security Awareness Training Campaign as a decision-aware workflow covering curriculum, launch, completion tracking, phishing simulation, escalation of non-completers, and effectiveness reporting. It runs on the EXISTING security-awareness training Control item (framework iso-27001 / nist-800-53, domains include awareness_training, control_owner = campaign owner): each cycle is one workflow instance attached to that Control — enriching it, never creating a duplicate control — and the prior cycle's archived instance on the same Control is the baseline for content refresh and simulation trends. No upstream workflow feeds this campaign; each cycle is driven by the campaign charter (trigger, window, audience segments, inclusion/exclusion rules, mandated topics, completion target, and phishing click/report thresholds) supplied at launch, together with the HR headcount and contractor/vendor rosters and the prior campaign report. In scope: running one campaign cycle end-to-end for all in-scope staff, contractors, and third parties with system access, against the campaign charter. Out of scope: routine LMS administration outside a campaign and HR disciplinary action beyond the policy consequence ladder. The named deliverables are the campaign effectiveness report and the indexed evidence archive, presented to the security governance / management review forum. No downstream workflow consumes it; the next cycle and any interim micro-training are scheduled at close (recorded on the campaign record — AssureSwarm has no compliance-calendar surface).
workflow · Context
ISMS Internal Audit & Management Review
Runs one ISO 27001 clause 9.2 internal audit and clause 9.3 management review cycle — including clause 10.1 corrective actions — against the existing Audit item for this cycle (audit_type=internal), whose scope, lead_auditor, and period dates already carry the ISMS audit-programme entry: the workflow enriches that Audit item and its findings, never creates a duplicate audit. Upstream it consumes the Annex A control population (Control items, framework iso-27001) and the applicability decisions in the Statement of Applicability, the risk register (Risk items) and treatment plan, the prior-cycle Audit and open Issue records, and the org's ISMS policies and procedures (Policy items) as audit criteria. Named deliverables: the internal audit findings report, the clause 10.1 corrective-action records (recorded on the finding Issue items), the management review pack, and the approved clause 9.3 minutes and action register. Out of scope: the certification-body external audit and day-to-day control operation. No upstream workflow feeds this cycle and no single downstream workflow consumes its output; at close the cycle is archived on the Audit item as retained ISMS documented information, and carry-forward items re-enter the audit programme (the next PLANNED Audit item), the risk register, or the next review's inputs.
workflow · Context
SOC 2 Readiness & Evidence Collection
SOC 2 Readiness & Evidence Collection runs ON an already-opened Audit item — the SOC examination engagement record (audit_type readiness, or external_attestation) whose scope (report type and Type 1/Type 2), examination period (period_start/period_end), and CPA firm (external_firm) are already set. That Audit item is an INPUT: this workflow enriches it and attaches its run to it, never creating a duplicate engagement. It consumes the organization's own Control library — the Control items, framework tagged soc2/soc1 — and no upstream workflow feeds it. In scope: one SOC examination cycle end to end — map the Control library to each in-scope Trust Services criterion (Security always; Availability, Confidentiality, Processing Integrity, or Privacy only where a customer commitment requires it) and SOC 1 control objective, close readiness gaps, run the provided-by-client (PBC) evidence request list with QA, and coordinate the CPA firm through fieldwork and follow-ups. Named deliverables: the criteria-to-control mapping matrix and graded gap matrix, the owned PBC evidence request list, the QA'd evidence set, and the cross-referenced PBC response package — all attached to the anchor Audit and its workflow instance. Out of scope: the SOC report the CPA firm drafts and continuous control monitoring between examinations. No downstream workflow is declared; this run's next-cycle seed artifacts (the PBC list and control calendar) stay on the close step as the de facto handoff to the next examination.
workflow · Context
Cryptographic Key Management Review
Periodic cryptographic key management review as a decision-aware workflow covering inventory, custody, rotation, algorithm strength, and verified remediation. The workflow instance attaches to the existing Audit item opened for this review cycle (audit_type it_audit or compliance; Audit.scope = the review scope statement; Audit.period_start/period_end = the review period; Audit.lead_auditor = the review owner) — enrich that record, never create a duplicate — and it links to the cryptographic Control items under review (domains cryptography_key_management, e.g. UC-CRYPTO-02, UC-CRYPTO-03). In scope: all managed key stores — cloud KMS, HSM partitions, certificate stores, secrets managers, and code-signing infrastructure — across in-scope environments. Out of scope: application-layer data classification and the identity provider, which are covered by their own reviews. No upstream workflow feeds this review; it is triggered by its periodic cadence, an incident, an audit request, or an algorithm-deprecation notice — scope is set on the Audit at kickoff, not handed off. The named deliverables are the signed cryptographic key management attestation (mapped to ISO 27001 A.8.24 and NIST SP 800-53 SC-12/SC-13) and the indexed, redacted evidence package filed against the anchor Audit; there is no downstream handoff workflow.
workflow · Context
Joiner-Mover-Leaver Access Lifecycle
Run one instance per HR-triggered joiner, mover, or leaver event as a decision-routed access-lifecycle control that enriches the EXISTING Control item for JML / user-access provisioning-deprovisioning (control library, domains=access_control_identity, framework nist-800-53 + iso-27001) - attach the instance to that control, never create a duplicate. Consume the authoritative HR event record from the external HR system of record (the trigger): classify the event, then provision role-based access, adjust with SoD checks on transfer, or evidence timely removal on exit, and file the named audit-ready access-lifecycle evidence package before closing. In scope: identity-provider, directory, HR-system, ERP, and connected-SaaS entitlements for the affected worker. Out of scope: HR record creation itself, physical-security badge policy, and system-owner entitlement design. The run is terminal - no upstream or downstream AssureSwarm workflow: it starts from the external HR event and ends at the archived evidence package attached to the Control item. The anchor Control links (item relationship) to the access Risk it mitigates.
workflow · Context
CSF 2.0 Profile & Maturity Assessment
Runs on an Audit item created for this assessment cycle (audit_type = readiness) — the CSF assessment engagement the workflow instance attaches to and enriches as it progresses (scope, period, rating, and report fields are written on that Audit item; every in-scope Control is linked to it so the controls-scoped profile is queryable). Build, against that boundary, a NIST CSF 2.0 Current Profile, a Target Profile, an organizational Tier rating, a subcategory gap analysis, and a CISO-ready remediation roadmap. The workflow originates on its own — scoping ingests prior CSF profiles and open POA&M (Issue) items as data, not as a named upstream handoff. In scope: rating the in-scope control set against the CSF 2.0 Core, setting target outcomes, assigning a Tier, and producing a prioritized roadmap. Out of scope: executing the remediation projects themselves and re-performing independent assurance testing. The named deliverable is the assessment package (profiles, gap analysis, Tier, posture report, roadmap, closure artifact), handed off to TWO downstream workflows that consume it rather than repeat the profiling: the Cybersecurity Assurance Review (always) and the AI Governance & Risk/Impact Assessment (only when AI systems fall inside the boundary).
workflow · Context
Threat Intelligence & Insider Threat Program
Runs on the existing Process item "Threat Intelligence & Insider Threat Program" (process_type=security_process, process_owner = program lead) — a long-lived program record related to the Control items it operates (UC-RISK-17, UC-BCDR-16, UC-GOV-37); each cycle is one recurring workflow instance attached to that Process, enriching the standing program rather than creating a new one. Decision-aware, covering NIST SP 800-53 PM-12, PM-16, and RA-10 and NIST CSF 2.0 ID.RA and DE.CM. In scope: cyclic intake and curation of threat intelligence into a validated intake register and intel cards, governed internal dissemination and TLP-marked outbound sharing packages, intel-driven threat hunts (producing the hunt summary) and any resulting investigation record, and privacy-guarded review of insider-threat indicators with a governed board disposition and a restricted insider case file, closing with a program-effectiveness report and a reperformable cycle archive. No upstream workflow feeds it; the only cross-run input is the prior cycle's carry-forward package (the carry-forward document from the previous instance's program-effectiveness report step, which closes each cycle), and each cycle emits the next one. Out of scope and handed off only in prose (no terminal handoff node): incident-response execution (the incident-response process, once an incident is declared at open-investigation) and HR/legal employment actions (owned by those functions within an insider case). Each cycle's intel-and-hunt track and its insider-threat track start in parallel from their own inputs.
workflow · Context
Data Retention & Secure Disposal
Each cycle runs as a workflow instance attached to the existing data-retention-and-secure-disposal Control item in the control library (UC-DATA-09/UC-DATA-10) — enrich that Control with this run's evidence, never create a duplicate control. A decision-aware cycle covering expired-data identification, disposition approval, verifiable disposal, media sanitization, evidence assembly, and stakeholder reporting. In scope: identifying and disposing of data whose retention has expired across in-scope stores (databases, file shares, document repositories, email archives, backup sets, and physical media) governed by the approved retention schedule. Out of scope: authoring the retention schedule itself — it is consumed as a standing input (the retention Policy item and its attached schedule), not produced here — and any data under an active legal or audit hold, which is fenced off from disposal. No upstream workflow feeds this cycle; it is triggered by the disposal calendar, a storage threshold, a system decommission, or a data-subject erasure request. It produces a signed disposition list, a disposal evidence package (job logs, hash manifests, chain-of-custody records, and certificates of destruction), a cycle dashboard, and an approved cycle report mapped to ISO 27001 A.8.10/A.7.10, NIST SP 800-53 SI-12/MP-6, and GDPR Article 5(1)(e). Downstream it hands nothing to another workflow: open exceptions, deferrals, and accepted gaps carry forward as Issue items in the risk/issue register, and schedule-maintenance gaps are forwarded to the retention-schedule owner as a closure notice.
workflow · Context
Incident Reporting Channels & Spillage Response
Standing operator workflow that runs on the existing Control item for the incident-reporting and information-spillage control (UC-IR-03; framework nist-800-53 | iso-27001 | nis2, domains incident_management_response) — one recurring workflow instance per operating cycle attaches to and enriches that Control item, never a duplicate. It consumes the prior cycle's carry-forward from the same Control: the last-sweep timestamp from the previous instance's close-and-archive record, plus the still-open corrective-action and obligation Issues linked to the Control. In scope: intake acknowledgment and triage routing across the monitored mailbox, hotline, and service portal; spillage containment/eradication and obligation assessment; and maintenance of the authorities and special-interest-group (SIG) contact register — spanning NIST 800-53 IR-6, IR-7, IR-9, and PM-15; ISO 27001 A.6.8, A.5.5, A.5.6; and NIS2 reporting duties. Named deliverables: the deduplicated intake register and acknowledgment log, the batch routing decision, the spill case with verified eradication, the obligation assessment and exposed-personnel training evidence, the refreshed authority/SIG contact register, the capability-health dashboard, the corrective-action register, and the archived operating record. Out of scope: full containment, investigation, and forensic response for genuine security events — those are handed off to the detect-to-respond workflow (via the route_to_incident_triage routing decision plus the linked intake Issues) rather than duplicated here.
workflow · Context
System Categorization, Security Planning & Authorization
Operator workflow for the system owner and authorizing official to categorize a system by impact and criticality, maintain the approved system security and privacy plan, authorize internal connections, and grant and track authorization to operate, as a decision-aware flow with categorization-approval and authorization branches. In scope: a single system — its impact and criticality categorization, the system security and privacy plan, internal-connection authorization, and the authorization-to-operate decision with reauthorization tracking. Out of scope: the control assessments and testing that feed the authorization risk view (consumed as an input) and enterprise categorization-policy setting; there is no upstream or downstream workflow, so any cross-workflow dependency is declared as a step input rather than routed.
workflow · Context
Information Security Program Governance Review
Standing operator workflow for the CISO's quarterly information security program governance review and its annual leg. Each cycle runs as one workflow instance attached to the existing "Information Security Program Governance" Process item (process_type: security_process, owner CISO), with the four governing Control items UC-GOV-06/09/10/15 linked to it. It is a decision-aware flow that enriches — never recreates — the senior-management-approved information security program plan (held as a Policy item) and the current role assignments every cycle, and branches into the written board report, workforce competency review, and plan reapproval when the annual interval or a significant change requires it. Named deliverables: the reapproved information security program plan (the Policy item, re-versioned and re-signed), the roles-and-authorities register, the annual written board report to the governing body, and the workforce competency review — each retained on the workflow instance. In scope: the program plan, security roles/authorities/reporting lines, the annual board report, and workforce competency for this organization; out of scope: executing the underlying protective controls and enterprise ERM governance, which are owned by their own workflows (coso-erm is referenced here only for oversight-of-design of the governance structure). There is no upstream or downstream workflow handoff — this cycle is genuinely self-contained: it starts from its own cadence trigger, consumes its own prior-cycle governance record, and seeds the next cycle at close.
workflow · Context
Security Policy Suite Review
Standing operator workflow for the security policy owner's annual (and change-triggered) review, redline, reapproval, and dissemination of the full security policy suite -- secure acquisition/development/configuration-management/maintenance, asset/media/physical protection, access/identity/personnel security, communications/cryptography, security awareness and cyber-hygiene, audit-logging/monitoring/system-integrity, contingency planning and disruption mitigation, and incident response. Anchor: each run is a workflow instance attached to the existing "Security Policy Management" Process item (process_type=security_process, process_owner=policy owner, frequency=annual) -- that instance IS the cycle record the tracked review items roll up to; the eight policy families are the existing Policy items the cycle enriches (never recreates). In scope: reviewing each Policy item against current risk and threat inputs, consolidating findings into one suite-level revision disposition, routing redlines to the right stakeholders, reapproving under accountable security leadership (writing Policy.approved_by / version / effective_date / next_review_date back onto each policy), and tracking dissemination and workforce acknowledgment as a single evidence set. Out of scope: authoring net-new policy domains and operating the technical controls the policies govern. The workflow has no upstream feeder workflow -- its inputs are the policy register (the eight Policy items), the prior-cycle workflow instance and its exported operating record, and the annual review calendar carried on Policy.next_review_date -- and no named downstream workflow; open corrective actions (Issue items) carry forward as explicit inputs to the next cycle. The eight domain reviews run in parallel and converge on a single revision-disposition decision.
workflow · Context
Security & Privacy Architecture Review Board
Standing operator workflow for the Security & Privacy Architecture Review Board. Each cycle runs as a recurring workflow instance attached to the existing UC-GOV-19 Control item (security & privacy architecture governance; framework nist-800-53 + cobit-2019) in the control library — it enriches that Control and its evidence trail, never creates a duplicate, and the chain of archived instances is that control's execution log (Control has no native execution-log field). The cycle maintains the enterprise, security, and privacy architecture views (across the business, data, application, technology, security, and privacy domains), runs a scheduled annual full-refresh branch, reviews solution designs and acquisition decisions for architectural alignment with a remediation loop, and pushes approved architecture updates into system security plans and acquisition requirements. It consumes: the prior cycle's archived baseline and architecture-view documents plus its open carryover Issue items; the live system/application inventory and mission/strategy statements (uploaded from external systems, no native item type); and the Risk items that form the security (category cyber_security) and privacy (category privacy) risk registers. Named deliverables: the refreshed enterprise architecture baseline package and drift log, the updated security and privacy architecture views with risk-crosswalk gap lists, the alignment assessment register, the pushed-updates package of SSP and acquisition-requirement changes, and the program-health dashboard. In scope: enterprise/security/privacy architecture maintenance, solution-design and acquisition alignment review, and SSP and acquisition-requirement updates. Out of scope: implementing the individual system security controls and running procurement themselves — those execute in the owning system-authorization (ATO) and acquisition/procurement workflows, which are the real downstream consumers of this cycle's SSP and acquisition-requirement updates. No upstream workflow feeds this cadence; it is triggered by the standing quarterly ARB cadence, the annual refresh date, or an ad hoc urgent design or acquisition submission.
workflow · Context
Privileged Access & Authorization Model Management
Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.
workflow · Context
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
Identity & Authenticator Lifecycle Administration
Standing operator workflow for identity issuance and ownership, shared-identifier exception handling, the dormancy and non-reuse sweep, identity proofing and credential binding, and the full authenticator lifecycle from verified issuance through protection, exposure scanning, and scheduled rotation or revocation. Each monthly cycle runs as a new workflow instance attached to the existing identity & authenticator lifecycle Control item (the UC-ACCESS-06/07/08 family; domains=access_control_identity, frequency=monthly) — the run enriches that standing control's evidence trail, never creating a duplicate control. It consumes no upstream workflow: its inputs are the prior cycle's own carry-forward Issue items (open corrective actions, pending shared-ID review dates, deferred rotations, each linked to the anchor Control) plus current request, source, and inventory extracts. Named deliverables: the issuance & ownership register, the dormancy/non-reuse sweep log, the shared-ID exception disposition and its compensating-control Control items, the identity-proofing evidence package with credential-binding records, the authenticator issuance/strength/default-change log, the protection/exposure-scan disposition, the rotation-and-revocation log, and the identity & authenticator lifecycle-health dashboard — all rolled into an archived, immutable operating record. Because no Identifier/Authenticator/Credential item type exists in the schema, per-identifier, per-binding, and per-authenticator records live as rows in these step-attached registers and logs; only exceptions, gaps, and carry-forwards are promoted to Issue items linked to the anchor Control, and approved shared-identifier waivers are recorded as compensating-control Control items plus a policy_exception Issue. In scope: unique-identifier issuance and ownership mapping for users, services, and devices; shared/group-identifier exceptions; the monthly dormancy and non-reuse sweep; identity proofing proportional to assurance level and credential binding; and authenticator issuance, hardening, protection, exposure remediation, rotation, and revocation across passwords, tokens, keys, and certificates. Out of scope: access authorization and entitlement reviews, joiner/mover/leaver approval routing, and privileged-session management, which are operated by their own workflows. There is no downstream handoff workflow — corrective actions and carry-forward items are tracked to closure within this cycle and seed the next monthly instance of the same control.
workflow · Context
Authentication Platform & Session Policy Operations
Monthly authentication-platform operating cycle. Anchor: this instance runs on the existing Process item for authentication-platform / session-management operations (process_type: security_process, frequency: monthly) — enrich that standing Process each cycle, never create a duplicate — with the four operated Control items UC-ACCESS-09/11/12/13 (framework tags carrying the standards mapping, domains: access_control_identity) linked to it. In scope: MFA enforcement and enrollment across remote, privileged, and sensitive-data access; secure log-on and federation-trust verification; lockout and anomalous-logon defense; session lifecycle controls (inactivity lock, automatic termination, concurrent-session limits, re-authentication for sensitive operations); and system-use, last-logon, and failed-attempt notices, across the IdP or SSO tenant, VPN or remote-access gateway, PAM tooling, and applications classified as housing sensitive data. Out of scope: identity provisioning and joiner-mover-leaver lifecycle, access certification, and privileged-access request approval, which are operated by their own workflows. There is no upstream workflow dependency: the instance is self-originating on its own initial inputs — the authentication-platform inventory (a document on the anchor Process, refreshed each cycle) and the prior-cycle operating record (the prior Workflow instance on the same Process plus its carried-forward open Issue items). The four operating areas run in parallel and reconverge at the platform-posture disposition. Named deliverables: the MFA enforcement-coverage register, the authentication-posture memo, the lockout-and-anomaly log, the session-policy compliance matrix, the banner-and-notice verification record, the platform-health dashboard and readiness summary, and the corrective-action register — each attached to its step, with every gap raised as a self_assessment Issue linked to the Control it degrades. There is no downstream handoff: this terminal recurring cycle seeds its own successor via carry-forward Issue items at close.
workflow · Context
Public Content & External Sharing Authorization
Standing operator workflow for the public-posting and external-sharing authorization queue plus the quarterly permitted-without-authentication register and public-content exposure sweep, run per publication request and each quarter. Each operating cycle runs as one instance that enriches the existing UC-ACCESS-14 Control item in the control library (NIST 800-53 AC-14/AC-21/AC-22, family AC, preventive, quarterly) — it never creates a new control, and the workflow instance itself is the durable audit trail attached to that Control. In scope: public-facing systems (public website, support portal, developer documentation, status page, social channels) and external data shares governed by sharing agreements. Out of scope: authenticated internal content and access provisioning. Consumes each cycle: the living public-content and external-share register, the permitted-without-authentication register, and the active-sharing-agreements register (all pre-existing, refreshed cycle over cycle); the information-classification scheme (a Policy item, policy_type: standard); and the prior cycle's open carry-forward Issues. Named deliverables: the classified intake register, the authorization-verification log, the per-request publication dispositions, the refreshed permitted-without-authentication register, the quarterly exposure-sweep dashboard and findings report, and exposure corrective-action Issues linked to the Control. This control runs standalone — no upstream workflow feeds it and no downstream workflow consumes its output; the per-request authorization path and the quarterly sweep path are independent and both close in this instance.
workflow · Context
Data Encryption & In-Use Protection Operations
Standing operator workflow for the quarterly encryption sweep across data at rest, in transit, and in use, including CISO-approved compensating controls where encryption is infeasible, with a dashboarded readiness classification and corrective-action tracking. Each quarterly instance runs against — and enriches — the existing Control item for the data-encryption / in-use-protection control (domains cryptography_key_management + data_protection_privacy, quarterly frequency, control_owner set); it never creates a duplicate control. It consumes the prior cycle's carry-forward — the still-open corrective-action Issue items and the active compensating-control Control items already linked to that anchor Control (there is no upstream handoff package). Named deliverables: the sensitivity-classified inventory register; the at-rest, in-transit, movement-control, and data-in-use findings registers; the CISO-approved compensating-control register; the program-health dashboard; the corrective-action register; and the archived operating record. In scope: every data store, transmission channel, and removable-media pathway that holds or moves sensitive or account data, plus high-sensitivity workloads that process data in use. Out of scope: key and certificate inventory and rotation, which are reviewed under the separate key-management program. Terminal by design: no downstream workflow consumes this cycle's output — open corrective actions and compensating controls carry forward as explicit inputs to the next quarterly cycle.
workflow · Context
Workplace & Remote Work Security Cycle
Standing operator workflow that runs the quarterly workplace and remote-work security cycle. Each quarterly instance ENRICHES the existing "Workplace & Remote Work Security" Process item (process_type: security_process, frequency: quarterly) — never a new one — and links to the three Control items it operates: UC-HR-07 (remote working), UC-PHYS-09, and UC-PHYS-11 (physical / output-device security). Three pillars run in parallel — the office walkthrough (clear-desk, clear-screen, output-device compliance), remote-work attestation verification and enforcement (device, screen privacy, secured environment, encrypted connectivity), and alternate-work-site control review and effectiveness assessment — and reconverge at the cycle-disposition decision, remediating exceptions in-cycle and tracking residual gaps to closure. Named deliverables: the signed walkthrough log and remediation log, the remote-work attestation-and-enforcement register, the alternate-site register and its site-effectiveness assessment, the corrective-action register, and the closure record. In scope: the offices and floors selected for this cycle, the remote-work population due for attestation, and currently approved and in-use alternate work sites. Out of scope: broader physical-security program design, HR remote-work policy authoring, and incident investigation itself. No upstream or downstream workflow feeds this cycle: it is self-seeding — at close it archives the run as the audit trail and hands its own next run a carry-forward package (open corrective-action Issues, the office/floor and alternate-site registers, next-quarter attestation renewals, and next alternate-site review dates) that is the explicit input to the next run.
workflow · Context
Facility Access Administration & Monitoring
Standing monthly operator workflow anchored to the existing **Facility Access Administration** Process item (process_type: security_process), with the operated Control items UC-PHYS-01, UC-PHYS-02, and UC-ACCESS-19 (control_category: physical, frequency: monthly) linked to it; each cycle runs as a fresh workflow instance and its reconciliation packages, decision forms, and Issue items attach to that instance. It covers credential authorization, entry control and visitor logging, key/badge custody and revocation — plus the monthly surveillance, access-log, and environmental-safeguards review with facilities, including the data-center and protected-asset access confirmation. In scope: authorization, issuance, and periodic re-justification of physical credentials; entry-control and visitor-escort enforcement; key/combination/badge custody, rotation, and revocation; and the monthly surveillance, access-log, visitor-record, and environmental-safeguards review across all facilities, perimeters, and secure areas including the data center and other protected-asset locations. Out of scope: logical/system access provisioning and full incident-response investigation — a confirmed intrusion or data-center compromise is handed off to the incident-response process. No upstream workflow feeds this capability; it runs on its own monthly cadence and on personnel-change and reported-anomaly triggers, and terminates at close-and-archive (the run itself is the retained audit trail — no other downstream workflow consumes the cycle package). Control references: NIST 800-53 PE-2/PE-3/PE-6/PE-8, ISO 27001 A.7.1–A.7.4/A.7.6.
workflow · Context
Environmental & Utility Systems Maintenance
Standing operator workflow for the monthly environmental and utility systems preventive-maintenance calendar — fire/water/environmental protection, emergency power and lighting, protected cabling, and electromagnetic shielding — producing the single maintenance-and-inspection log required as evidence. Anchor: each monthly cycle runs as a new workflow instance attached to the existing umbrella physical/environmental-maintenance Control item in the control library (control_category=physical, frequency=monthly, framework nist-800-53|iso-27001|nist-csf-2), with the specific UC-PHYS-03/05/06/07 Control items linked — the run enriches that Control's execution history, never creates a duplicate control. Consumes its inputs directly with no feeder workflow: the PM calendar entry, the fire/water/power/lighting/cabling/shielding asset inventories, and the independent maintenance vendor's service tickets and test records (the vendor is a Vendor item in the third-party register; its tickets attach as step evidence). The prior cycle's archived export and its still-open deficiency Issues (linked to the anchor Control) are the only carry-forward channel. In scope: the physical environmental and utility protection systems for the in-scope facilities and rooms (fire detection and suppression, water-damage detection and shutoff valves, temperature/humidity monitoring, UPS and generators, emergency lighting and power shutoffs, protected cabling and wiring closets, and electromagnetic shielding). Out of scope: logical access, network security, and the building's base construction. There is no downstream workflow: this standing cycle drains to its own retained archive and seeds next month's cycle with the corrective-action Issues left open.
workflow · Context
Equipment Maintenance, Movement & Marking Control
Standing operator workflow that runs on the existing physical-equipment Control item (the UC-PHYS-04/08/10/12 control, domains=physical_environmental_security, frequency=quarterly): each maintenance, movement, or installation/relocation event opens one workflow instance against that Control item and enriches it with the cycle's evidence, never creating a duplicate control. It covers equipment maintenance, asset movement, and installation/relocation siting and marking, converging into the quarterly reconciliation that ties all three evidence streams together. In scope: scheduled and unscheduled maintenance events, asset delivery/removal/movement events through isolated loading areas, and installation/relocation siting and hardware marking within the facility's data halls, plus the quarterly reconciliation of the three. Out of scope: media sanitization and data-disposal workflows and physical access-control administration, which are governed by their own controls. Named deliverables: the maintenance record pack, the asset movement record with designated-asset tracking reconciliation, the siting-and-marking record, and the consolidated quarterly reconciliation evidence set, plus Issue items for faults, movement investigations, and marking gaps. No upstream workflow feeds this cycle and it hands off to no downstream workflow; it is triggered directly by a maintenance, movement, installation/relocation, or quarterly-reconciliation event, is owned by the Data Center Operations Coordinator, and its close-and-archive step seeds its own next cycle via carry-forward Issue items linked to the Control.
workflow · Context
IT Asset Inventory & Classification Upkeep
Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).
workflow · Context
Endpoint, Media & Information Handling Custody
Standing monthly operator desk for endpoint, media, and information-handling custody. The workflow instance is the monthly operating cycle attached to the EXISTING Control item for this custody control (control_id UC-ASSET-04/06/08 and UC-NET-12, Control.frequency monthly, Control.framework spanning nist-800-53, iso-27001, soc2, pci-dss) — each cycle enriches that standing Control rather than creating a new one. In scope: fleet endpoint safeguard and acceptable-use verification, off-premises and external-system use, port/I/O/sensor and collaboration-device restriction, removable-media authorization/custody/sanitization/destruction, and the information-transfer rulebook and agreements across electronic, physical-courier, and verbal channels. Out of scope: identity/access provisioning and network-perimeter engineering, which run under their own controls. No upstream workflow feeds this desk — the prior cycle's close-and-archive export is the carry-forward input that seeds each run (the fleet inventory, media custody register, and transfer rulebook are its own standing inputs). Named deliverables: the fleet-safeguard exception list, the endpoint-posture and custody-cycle disposition decisions, the removable-media authorization log and custody register, sanitization verification evidence and retained destruction certificates, the transfer-rule status, and two corrective-action registers backed by Issue items. Endpoint, media, and transfer streams run in parallel and reconverge at two decision checkpoints that route exceptions to tracked corrective action; terminal by design — it hands off to nothing but its own next monthly cycle.
workflow · Context
IT Availability & Resilient Failure Operations
Standing operator workflow for the monthly IT availability and resilient-failure-operations cycle: batch and processing monitoring with incident and problem resolution, backup and restore verification, availability-to-SLA tracking, network capacity and DoS-mitigation posture, fail-secure and alternate-communications readiness, and the mean-time-to-failure replacement queue with verified fail-safe procedures, as a decision-aware flow that escalates an urgent reliability gap immediately and rolls routine findings into a single end-of-cycle corrective-action log. Each monthly instance runs against the EXISTING Control item for this IT-availability and resilient-failure-operations control (frequency: monthly; framework: nist-800-53 + sox; domains: business_continuity_disaster_recovery, network_communications_security, incident_management_response) — it enriches that standing control with the cycle's evidence rather than creating a new record: per-stream evidence attaches as documents on the workflow instance's steps, operational failures and gaps become Issue items linked to that Control, and the named deliverable is the signed monthly control record (the classify-cycle-disposition form plus its disposition summary), backed by the monitoring roll-up, incident-and-problem log, backup-and-restore summary, availability dashboard, capacity and fail-secure verification records, and the corrective-action register. In scope: the in-scope batch jobs and system processing, network services and communications paths, and components tracked for mean-time-to-failure named in the operating brief, measured against their defined availability and processing service expectations; out of scope: application change management, access provisioning, and physical-environment controls, which are operated by their own workflows. This is a standing monthly cycle with no upstream workflow dependency and no downstream handoff — its inputs are the organization's own scheduler and monitoring feeds, backup history, capacity telemetry, and asset/MTTF inventory; its archived record seeds the next monthly instance of the same control.
workflow · Context
Change & Release Management (CAB)
Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.
workflow · Context
Secure Baseline & Integrity Drift Management
Standing monthly operator workflow for the secure-baseline and integrity-drift cycle: maintain and approve hardening baselines and least-functionality settings against accepted industry standards, run configuration-compliance scanning and remediate drift as findings, triage file-integrity, hash/signature, and secure-boot alerts while verifying security functions self-test correctly, and keep the configuration management plan current annually or after significant environment change. In scope: system components and network security controls governed by CM-2/CM-6/CM-7/CM-9 and SI-6/SI-7 (ISO 27001 A.8.9, PCI DSS Req.1/Req.2, NIST CSF PR.PS-01/DE.CM-09). Out of scope: incident containment and response — unexplained changes are escalated as potentially adverse events to the detect-to-respond incident-analysis practice rather than contained here. Anchor: each monthly run is a recurring workflow instance attached to the EXISTING secure-configuration Control item (the CM-2/CM-6/CM-7 hardening-baseline control — domains=secure_configuration_change_management, frequency=monthly, framework nist-800-53/pci-dss/iso-27001); the cycle enriches that standing Control and never creates a new one. No upstream workflow feeds this cycle — it is self-seeding: its inputs are the prior instance's archived operating record, the approved hardening-baseline standards (Policy items linked to the Control), the open drift/integrity backlog and baseline-reassessment carry-forward (Issue items linked to the anchor Control), and the CM-plan review calendar. Named deliverables: the approved hardening-baseline standards and least-functionality list, the configuration-compliance scan-result register, the integrity-alert and self-test register, drift and corrective-action findings (Issue items linked to the Control), the reviewed configuration management plan (Policy item), the cycle-health dashboard and readiness summary, and the signed, archived cycle operating record. The only cross-workflow handoff is the adverse-event escalation package handed to the detect-to-respond incident-analysis practice.
workflow · Context
Authorized Software & Component Integrity Control
Authorized Software & Component Integrity Control run as a decision-aware monthly cycle that enriches the existing "Authorized Software & Component Integrity" Control item in the control library (control_id UC-CONFIG-05/UC-CONFIG-06, frequency monthly, domains secure_configuration_change_management + third_party_supply_chain_risk) — each run is a workflow instance attached to that Control item, never a newly created control. It originates on its own (parallel entry threads consuming the cycle's own software-inventory, catalog/allowlist, install-rights, supplier-intake, and telemetry feeds) and also carries forward the prior cycle's still-open Issue items linked to the same Control. In scope: reconciling installed software across the in-scope endpoints, servers, and system images against the approved catalog and technical allowlist (the discrepancy register), triaging unauthorized installations to catalog-update / removal / escalation, verifying installation rights stay restricted to the authorized-installer roster from trusted sources (the install-rights and trusted-source exception list), tracking usage against license entitlements (the license-position report), and verifying supplier trust and signature integrity for every component acquired this cycle (the component verification register). Named deliverables — the discrepancy register, triage dispositions, catalog/allowlist change record, per-host removal evidence, install-rights and trusted-source exception list, component verification register, blocked-component investigation findings, and license-position report — are archived as the signed monthly cycle record on the workflow instance. Out of scope: incident containment and forensics — any suspected-malicious component is handed off, evidence intact, to the incident-response workflow, which owns that containment; this control cycle does not duplicate it.
workflow · Context
Malware, Email & Web Content Defense Operations
Standing operator workflow for anti-malware coverage, detection handling, spam and phishing filtering, and mobile-code and website-content control, run on a monthly cadence by the security operations malware defense lead. Each monthly run is a new workflow instance attached to the existing Process item "Malware, Email & Web Content Defense Operations" (process_type: security_process, frequency: monthly), with Item relationships to the Control items it operates — UC-VULN-05 (malicious code protection) and UC-NET-13 (mobile code) in the control library (framework: nist-800-53, iso-27001, pci-dss). In scope: every system component commonly affected by malicious software, the email and web filtering entry and exit points, the mobile-code technologies in use, and website category and reputation filtering. Out of scope: endpoint patching and vulnerability remediation, incident response beyond first-line quarantine and alerting, and network firewall rule management. No upstream workflow feeds it: the monthly scope, the in-scope component and channel list, the accountable owners, and the prior-cycle carryover — the previous instance's open Issue items and step documents — are its own initial inputs. It produces the coverage reconciliation report, the detection-and-response log, the mobile-code authorization list, the tuned email/web and website-content filtering packages, a capability-health dashboard, a signed readiness classification, and a corrective-action register. It is terminal by design: rather than hand off to a downstream workflow, the close-and-archive step preserves the signed operating record under retention and loops carry-forward Issue items into the next monthly cycle.
workflow · Context
Deception, Honeytoken & OPSEC Concealment Operations
Standing quarterly operator workflow that runs against the EXISTING deception/OPSEC concealment Control in the control library (control_type: detective, framework: nist-800-53, frequency: quarterly, mapped to UC-NET-10/UC-VULN-11/UC-NET-11) — each quarter's instance enriches that Control's operating history and is archived as its audit trail, never creating a duplicate control. In scope: deploy and reposition honeypot/honeynet decoys and honeyclient sandbox detonation ahead of user delivery, seed/monitor/functionally-test honeytoken/beacon/watermark taint mechanisms across systems and datasets, and run the OPSEC process that identifies critical operational information (Risk items), analyzes adversary collection paths, and deploys concealment and misdirection countermeasures (Control items) on the cycle's designated systems, segments, and datasets. Originates on its own: the four operating streams (OPSEC, decoys, sandbox, taint) are parallel entry points fed by the organization's own asset, threat-intel, and inventory data — no upstream workflow feeds it. Named deliverables: the isolation-verified deception estate (deployment/repositioning plan + isolation-verification record), sandbox pipeline test results, the seeded taint-mechanism placement inventory, the OPSEC critical-information register with countermeasure register, the cycle detections timeline, and the program-health readiness dashboard. Out of scope: incident containment and eradication — confirmed activations are handed to the incident-response workflow with a preserved chain-of-custody evidence package (that handoff fires only on the activations-detected branch), rather than contained here.
workflow · Context
Secure Development & Release Security Gate
Each run attaches as a workflow instance to the existing Control item for the secure-development/release-security-gate control (domains: secure_development_sdlc + vulnerability_patch_management) — enrich that Control, never create a duplicate; release runs and the quarterly checkpoint are separate instances on the same anchor Control. This workflow originates on its own artifacts (the release candidate, design artifacts, and the standing portfolio registers) and receives no upstream handoff package. Decision-aware: it branches on trigger type. In scope — for a release or major upgrade entering development, run security-and-privacy-by-design engineering, security test-plan execution, and runtime-hardening verification as parallel evidence streams, then resolve the release security disposition and assemble the release security evidence package with its acceptance-criteria index; for the quarterly portfolio checkpoint, run the vulnerability, patch, and end-of-life software review, publish the portfolio-health dashboard, and log corrective actions. Out of scope — the final production go/no-go, which the separate SDLC gate review workflow owns using the evidence package this workflow hands off to it. The release track and the quarterly track never force each other's steps.
workflow · Context
Controlled Hardware & System Maintenance
Standing operator workflow for the hardware and system maintenance desk, anchored on the existing Process item "Hardware & System Maintenance" (process_type: it_general_control, process_owner: the maintenance coordinator, frequency: monthly): each monthly cycle runs as one workflow instance on that Process — enrich the standing Process, never create a duplicate desk. It schedules and approves maintenance, repair, and replacement, routes execution across on-site, off-site, and nonlocal (remote) sessions with the right tool, personnel, and connection controls, and verifies security controls after every completion. The governing requirements are the linked Control items UC-CONFIG-07 and UC-CONFIG-08 (framework nist-800-53, nist-csf-2; MA family). In scope: scheduling, approval, execution, and post-work verification of maintenance, repair, and replacement for in-scope hardware and systems across on-site, off-site, and nonlocal sessions, plus support/spare-parts tracking and end-of-life disposition. Out of scope: procurement of net-new assets and software patch/change management, which run in their own workflows. No upstream workflow feeds this desk; it consumes its own maintenance queue, open work requests, the asset/hardware register export (there is no native Asset item type — the register is uploaded at the first step), and manufacturer maintenance schedules, and it seeds its own next cycle at close. Named deliverables: an approved maintenance schedule (XLSX), per-mode execution-evidence logs, a post-maintenance security-control verification report, a support/spare-parts disposition status, a maintenance-desk health dashboard, and a closure record — with exceptions, control drift, and gaps promoted to Issue items and a corrective-action register. Downstream, end-of-life "remove from service" dispositions hand off to the equipment-disposal / media-destruction workflow, and any out-of-scope drift found during post-maintenance verification hands off to the incident or change-management workflow.
workflow · Context
Network Segmentation & Boundary Rule Management
Network Segmentation & Boundary Rule Management as a decision-aware operator workflow covering trust-zone maintenance, gated rule-change implementation, boundary threat monitoring, the quarterly segmentation and rule-set review, and cross-domain exchange-policy enforcement. This cycle runs on the EXISTING boundary-protection Control item (domains network_communications_security; framework NIST 800-53, NIST CSF 2.0, ISO 27001, SOC 2; frequency quarterly; the boundary control owner as control_owner) — each quarterly run is one workflow instance attached to and enriching that Control, never a new control record. In scope: the trust-zone model, the managed interfaces (firewalls, gateways, proxies) mediating traffic between zones, the external boundary and key internal boundaries, and the cross-domain interconnection points, all under a deny-by-default baseline (NIST 800-53 SC-7, SC-16, SC-46; NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6). No upstream workflow feeds this cycle; it self-seeds from its own prior-cycle carry-forward — open corrective-action Issue items linked to the Control plus the prior run's closure record and archived rule-change record log. Named deliverables: the reconciled trust-zone model, the verified rule-change record log, the boundary threat-monitoring summary, the cross-domain exchange-policy enforcement report, the quarterly segmentation & rule-set review report, the boundary-posture dashboard, and corrective-action Issues linked to the Control. Downstream, it hands off only to its own next cycle via the carry-forward closure record; a confirmed intrusion is escalated to the incident-response workflow (out of scope), as are host/endpoint controls.
workflow · Context
Secure Connectivity & Network Trust Services Operation
Standing operator workflow for remote/wireless/mobile access re-authorization, session trusted-channel and termination verification, and DNSSEC/name-resolution and time-service assurance, as a decision-aware quarterly cycle that contains rogue access before continuing and routes gaps to tracked corrective action. Each quarterly instance attaches to the existing standing Process item (process_type: security_process, frequency: quarterly) for Secure Connectivity & Network Trust Services — it enriches that Process cycle-over-cycle, never creating a duplicate — and that Process is related to the existing Control items UC-NET-02, UC-NET-03, and UC-NET-07 the cycle operates. In scope: remote-access methods, wireless networks, and organization-controlled mobile devices; systems hosting security-relevant sessions; authoritative DNS zones, recursive and caching resolvers, and authoritative time sources. Out of scope: endpoint hardening and identity/credential lifecycle beyond out-of-band key delivery. The cycle runs on its own quarterly trigger and consumes no upstream workflow handoff package; it produces the re-authorization register, the sweep and containment logs, the session-trust and name-resolution/time assurance records, the connectivity trust-posture dashboard and summary, and a corrective-action register — closing into an internal carry-forward that seeds the next quarterly instance (no handoff to a distinct downstream workflow).
workflow · Context
Identity Assurance Review
This review runs on an Audit engagement item created for the review cycle (audit_type: it_audit; scope: the identity assurance boundary) — the workflow instance attaches to that Audit, and the five in-scope UC-ACCESS Control items (UC-ACCESS-07/08/09/11/12) link to it. It is self-originating: no upstream workflow feeds it — it starts from the review trigger, the governing controls, and the collected evidence. Review the IAL, AAL, and FAL assurance requirements against the current identity proofing, authentication, and federation controls for the in-scope systems, then remediate, document, and hand off open gaps. It produces the target-level register, the current-state control inventory, the scored gap register, the per-control assurance determination memo, and the compiled assurance review package; each open gap is recorded as an Issue (POA&M) item linked to its UC-ACCESS Control and the anchor Audit. In scope: NIST SP 800-63 identity assurance levels for the systems named in the locked workplan. Out of scope: broader access provisioning, joiner-mover-leaver lifecycle, and privileged-access certification. Hands off the assurance determination and any open POA&M items to the Security Control Assessment and POA&M Remediation workflow.
workflow · Context
Platform Isolation & Separation Enforcement
Platform Isolation & Separation Enforcement as a decision-aware operator workflow. Each semiannual run attaches to the existing platform-isolation Control item — UC-NET-04 (framework nist-800-53, family SC, frequency semi_annual, control_owner = security architect), with sibling Controls UC-NET-05 and UC-NET-06 linked — enriching that standing control with a fresh cycle of evidence rather than creating any new anchor; consecutive instances stack on the same Control as its cycle history. Three verification streams run in parallel — user/system-management/security function and sensitivity-domain separation, shared-resource sanitization and covert-channel bandwidth reduction, and hardware- and software-enforced separation-mechanism integrity — and converge into a single posture review and closure. It consumes the prior cycle's still-open findings (Issue items carried forward on the anchor Control) plus live platform telemetry, and produces named deliverables: the function-and-domain separation matrix, the shared-resource sanitization report, the covert-channel analysis report, the hardware/software-mechanism verification report, a consolidated isolation-posture dashboard and evidence summary, and a signed cycle closure record. In scope: the semiannual verification and corrective-action closure of platform isolation across all in-scope platform components. Out of scope: the platform-engineering re-architecture behind a fix (tracked here as corrective-action Issues, executed by platform engineering) and boundary/network-protection controls owned by their own cycle. No upstream workflow feeds this cycle; its only handoff is downstream to its own next run — open corrective actions are left as OPEN Issue items on the anchor Control and arrive as explicit inputs to the next semiannual instance.
workflow · Context
Resilient Architecture & Non-Persistence Operations
Standing operator workflow that runs each quarter against the existing NIST 800-53 resilient-architecture / non-persistence Control item in the control library (framework=nist-800-53, SI/SC family covering SI-14, SI-21, SI-22, SI-23, SC-25, SC-29, SC-36, frequency=quarterly, control_owner = Infrastructure Architecture Lead); the recurring instance attaches to and enriches that Control — it never creates a new control. In scope: non-persistent provisioning and information refresh, diverse sourcing and fragmentation of high-value data, and the resilient-architecture review of thin nodes, technology heterogeneity, and distributed processing and storage against current threats. It consumes no upstream workflow handoff; its inputs are the standing non-persistence and resilient-architecture inventories — the critical-information suppliers adopt the native Vendor type, while the infrastructure components, information stores, and fragmentation entries have no native item type and are held as register documents on the anchor Control — plus any open carryover Issue items from the prior cycle. Named deliverables: the refresh-and-attestation log, the sourcing-diversity and fragmentation-verification report, the thin-node / heterogeneity / distribution assessments, the combined resilience-posture dashboard and posture-review summary, and the adjustment-action register; exceptions, drift, and gaps normalize into Issue items linked to the Control. Out of scope: incident response itself — a suspected refresh-source compromise is contained and escalated to the incident-response team (an escalation, not a workflow handoff) — and application-layer change management. This is a terminal recurring cycle: close-and-archive exports the run as the durable operating record and seeds the next quarter's inputs.
workflow · Context
Audit Logging Coverage & Integrity Operations
Monthly operator cycle that verifies audit-logging coverage against the security-relevant event catalog, validates record content-completeness and clock synchronization, and confirms log protection, alerting, and retention, producing the coverage matrix, record content-completeness results, clock-drift report, and retention and capacity attestation evidence pack each cycle. Each instance attaches to the EXISTING audit-logging Control in the control library (control_id UC-LOG-01; framework nist-800-53 / iso-27001 / pci-dss / nydfs-500; domain logging_monitoring_detection; monthly frequency), with UC-LOG-02 / UC-LOG-03 linked by item relationships — enrich that Control's operating history, never create a duplicate control. Every gap, remediation, and carry-forward is logged as an Issue related back to that Control. In scope: every in-scope system, application, and network component, the security-relevant event catalog, and log protection and retention configuration. Out of scope: SIEM detection-rule tuning and incident investigation — surfaced detection gaps hand off to the SOC / SIEM-operations and incident-response workflows, not this cycle. No upstream workflow feeds this cycle; the prior cycle's open corrective-action and carry-forward Issue items (related to the anchor Control) plus the prior cycle's archived workflow instance are its only inputs, and close-and-archive seeds the next monthly run of itself.
workflow · Context
Security Monitoring & Detection Operations
Each weekly cycle is a recurring instance attached to the existing continuous security-monitoring Control item (domains: logging_monitoring_detection, control_type: detective, frequency: weekly) — the cycle enriches that standing Control with its operating record, never creating a duplicate control. It consumes the prior cycle's carry-forward (unresolved queue Issues, open watchlist entries, open corrective actions) and the documented continuous-monitoring strategy (a Policy item linked to the Control), and produces named deliverables: the deployment coverage-and-effectiveness assessment, the enriched central SIEM analysis queue, the maintained detection watchlist, and the signed cycle security-status report. In scope: verifying monitoring deployment and effectiveness, working the central SIEM threat-intel analysis queue, triaging flagged anomalies, maintaining the detection watchlist, reporting security status to the defined roles, and verifying continuous protection-service health and tuning across hosts, networks, and applications at both the perimeter and the interior. Out of scope: incident containment, eradication, and recovery — confirmed security events are handed off mid-cycle to the Security Incident Response workflow rather than duplicated here.
workflow · Context
User Activity & External Exposure Monitoring
Monthly operator cycle for the standing user-activity and external-exposure monitoring control (UC-LOG-07/UC-LOG-11) — a detective, monthly-frequency Control that already exists in the control library. Each cycle runs as one workflow instance attached to that existing Control (enrich it — never create a duplicate control); the accountable owner and cadence come from Control.control_owner and Control.frequency=monthly. The instance runs the restricted privileged/remote session and acceptable-use review alongside the external open-source and dark-web exposure sweep, then converges every confirmed finding from both halves — each recorded as an Issue item linked to the anchor Control — into one consolidated restricted case log (XLSX) for security-event evaluation. Consumes upstream: no workflow feeds it — session capture and the exposure sweep are the two parallel entry points; each cycle draws on the standing monitoring program's authorized-reviewer roster, the acceptable-use policy and employee-monitoring disclosure notice (Policy items), the external search-set markers, and the prior cycle's carry-forward Issues. Named deliverables: the personnel-activity and exposure disposition decisions, the HR/legal referral and takedown Issues, the cycle-health dashboard, and the consolidated restricted case log. Downstream handoff: confirmed findings hand into the security-event evaluation queue — an informal handoff recorded as a reference on each case-log entry and in each Issue.description, since the graph has no terminal handoff node. In scope: privileged/remote session review, personnel acceptable-use monitoring, and the external open-source/dark-web exposure sweep for one monthly cycle. Out of scope: the automated SIEM alerting pipeline and the downstream security-event evaluation itself.
workflow · Context
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
Incident Response Readiness Program
Standing operator workflow that runs against the EXISTING incident-response Control item — UC-IR-01 (domains=incident_management_response, frequency=annual) — with the training-and-testing Control UC-IR-02 linked to the same instance; both carry framework=[nist-800-53, iso-27001], and those governing standards drive the plan's required elements. It maintains and approves the written IR plan (a Policy item, policy_type=procedure, framework=[nist-800-53, iso-27001], review_frequency=annual, whose governed redline attaches to the item), distributes and protects it to named responders, delivers role-based training, runs the scheduled capability test (an Audit item, audit_type=readiness, linked back to the two Controls), and feeds exercise and training gaps back into the plan and training program as corrective-action Issue items (source=self_assessment). Named deliverables: the redlined IR plan on its Policy item, the exercise after-action report, the IR readiness dashboard, and the routed corrective-action register (Issue items). In scope: the IR plan's required elements (mission and scope, incident definitions and severity structure, roles and responsibilities, communication paths, and business-continuity/third-party coordination), the named-responder and leadership training population, and the scheduled capability test. Out of scope: live incident handling itself — this workflow builds and tests readiness, it does not run the response to an active incident. It runs on an annual cadence and off-cycle whenever a significant incident or a material organizational/system change occurs; no upstream workflow feeds it and it hands off to no downstream workflow — identified gaps re-enter this same workflow as corrective-action Issues.
workflow · Context
Resilience & Failover Readiness Verification
Standing quarterly operator workflow that verifies alternate storage, alternate processing, and diverse telecommunications capability (UC-BCDR-04) and validates the safe-mode, alternate-communications, and alternate-security-mechanism design configured on critical systems (UC-BCDR-11). Each quarterly instance runs against the EXISTING UC-BCDR-04 alternate-capability Control item in the Control library (frequency quarterly), with the UC-BCDR-11 degraded-mode Control item linked as the second in-scope control — it enriches the evidence trail on those existing controls, never creating a duplicate control. Self-originating: it consumes no upstream workflow handoff, reading the two governing Control items (control_id UC-BCDR-04 and UC-BCDR-11), the prior quarter's archived readiness instance, and the open corrective-action Issues carried forward on those controls; all operational reference data (backup schedule, alternate-site media/replication log, site records, telecom inventory, system design specs and configs) enters as PBC uploads on the verifying step, since none of it is item-typed. In scope: confirming that this alternate capability and degraded-mode design remain current, hazard-separated, secured to primary-site parity, and ready to assume operations within RTO. Out of scope: the live failover exercise that actually cuts over to the alternate site, run separately by the assure-line DR test workflow that consumes the readiness state this workflow maintains. Named deliverables: six verification memos (storage-site, processing-capability, telecom, safe-mode, alternate-communications, alternate-security), a readiness dashboard and a signed readiness summary, and a corrective-action register — every gap converts into an owned corrective-action Issue (issue_type: deficiency, source: self_assessment) linked to the impaired Control, with any recovery-time-impacting gap escalated immediately rather than held for end-of-cycle closure. Downstream handoff: the archived readiness summary and dashboard serve as the readiness-state package the assure-line DR test workflow reads (no terminal handoff node exists yet — see the closure step).
workflow · Context
IT Operations & Capacity Management Cycle
Standing operator workflow for the weekly IT operations and capacity management cycle. It runs on the EXISTING **Process** item "IT Operations & Capacity Management" (process_type: operational, process_owner: IT operations manager, frequency: weekly): each weekly cycle is a new workflow instance attached to that Process — the Process is enriched, never recreated — with the operated **Control** items (job-scheduling, infrastructure-monitoring, and capacity controls; frequency: weekly) linked to it via a Control ↔ Process relationship. The instance executes and reconciles daily job scheduling, processing, infrastructure monitoring, and facility management against documented procedure, then assesses capacity and utilization against forecast demand, triggers capacity additions and priority-allocation safeguards ahead of threshold breach, and produces the named evidence set: the weekly operations review minutes, the consolidated exception log, and the capacity-and-utilization report (plus a recurring capacity-and-utilization dashboard). In scope: daily job scheduling, processing, infrastructure monitoring, and facility management for the operator's named in-scope systems and facilities, plus the weekly capacity and utilization review of infrastructure, data, and software against forecast demand. Out of scope: incident response, change management, and disaster-recovery testing, which run as their own workflows; this cycle raises corrective actions and capacity-addition requests (tracked as Issue items) that feed change management in substance but models no explicit handoff node — it is a terminal, self-originating operate-line cycle that does not itself execute infrastructure changes. No upstream workflow feeds it: its inputs are the operator's own job schedules, monitoring and facility feeds, the governing operating-procedure and capacity-threshold and quota **Policy** items, and the prior cycle's carryover **Issue** items (created when the signed weekly operations review closes the cycle) that arrive as tracked inputs — and the cycle seeds its own next-cycle carryover the same way.
workflow · Context
ISMS Risk Assessment & Treatment Cycle
Perform an ISO 27005 information security risk assessment and treatment cycle for a defined ISMS scope. The recurring cycle instance attaches to the existing Process item (process_type=security_process) that represents the ISMS scope — enrich that item, never create a duplicate; the risk register it produces is the set of Risk items the run creates and updates. The cycle: establish context and risk criteria, identify information security risks, analyze and evaluate them against the criteria, select treatment options, draft the risk treatment plan, obtain residual-risk acceptance, and retain the documented information. In scope: risk identification through treatment planning and residual-risk acceptance for the ISMS boundary. Out of scope: the Statement of Applicability control-applicability determination and control operating-effectiveness testing, which are handled downstream. This workflow has no upstream workflow — its boundary and inventory are initial inputs: the in-scope business processes are existing Process items, while the asset/information inventory and risk criteria are uploaded documents (no native Asset type). It produces the named deliverables — the current risk register (Risk items), the Risk Treatment Plan (RTP), and the SoA inputs — handed off to the ISO 27001 SoA Review & Controls Assessment workflow.
workflow · Context
Supply-Chain Integrity & OPSEC Operations
Standing monthly operator workflow run against the existing supply-chain integrity Control item (UC-TPRM-07, frequency=monthly, domains=third_party_supply_chain_risk), with the OPSEC need-to-know Control (UC-TPRM-09) linked as the second in-scope control — enrich these existing Control items, never recreate them; the workflow instance attaches to the anchor Control as the durable operating record. Two concurrent workstreams. In scope: receipt-time tamper-evidence and authenticity inspection of critical systems and components, provenance and chain-of-custody upkeep, suspected-counterfeit disposition (each raised as a finding Issue linked to the anchor Control and the implicated Vendor) with inspector-training refresh where a lapse is found, and the OPSEC need-to-know review of the sensitive supply-chain information register with remediation of any overexposure. Named deliverables: the authenticated provenance and chain-of-custody register, the counterfeit-disposition cases, the OPSEC exposure-review worksheet, and the confirmed need-to-know-restricted disclosure footprint. No upstream workflow feeds this cycle — its inputs are the period's own receiving log and the sensitive supply-chain information register. This is a terminal standing control: procurement and vendor onboarding, contract-level third-party risk assessment, and facility physical security are out of scope, each handled by its own workflow; a substantiated counterfeit or compromised supplier is escalated to the third-party/vendor risk workflow rather than resolved here.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
Outsourced & Critical-Component Development Oversight
Quarterly outsourced- and critical-component development oversight, run as a recurring operating cycle against the EXISTING Control item for outsourced/critical-component secure development (UC-SDLC-10 / UC-SDLC-11; domains secure_development_sdlc + third_party_supply_chain_risk; NIST 800-53 SA-20/SA-21/SA-23, ISO 27001 A.8.30) — the workflow enriches that Control, it never creates a duplicate. Each quarter it inventories the active outsourced/third-party development engagements (enriching the Vendor register), verifies contract secure-development / IP-ownership / audit-rights terms, traces deliverables to requirements with security-test evidence on file, screens critical-system developers before access, refreshes the register of components critical to security or mission, and re-tests the specialized-development rationale and assurance evidence. It consumes the prior cycle's carry-forward Issue items (open corrective actions, contract renewals, components due for rationale review) and the archived prior workflow instance's registers; every gap it surfaces becomes an Issue linked to the anchor Control, giving one queryable corrective-action population. In scope: active outsourced and third-party development engagements and the register of components critical to security or mission; out of scope: internal-only development with no third-party contributor and general procurement risk unrelated to development. Self-terminating: no downstream workflow consumes this cycle's output — corrective actions are tracked to closure within this workflow and carried forward to the next quarter.
workflow · Context
Technology Lifecycle & Capacity Review
Standing operator workflow for the quarterly solution-asset lifecycle review and the availability/capacity planning cycle, from asset reconciliation and end-of-support disposition through capacity monitoring, corrective planning, and prior-period target validation. Each quarterly run is a recurring workflow instance attached to the EXISTING technology-lifecycle-and-capacity-management Control item (UC-SDLC-12/13; frequency = quarterly; control_owner = the IT control owner) — the instance enriches that standing Control and its linked records, never a fresh duplicate; the governing COBIT 2019 / NIST 800-53 mapping rides on Control.framework. In scope: the in-scope solutions, applications, and supporting infrastructure components (the services they run are Process items) with named owners, and the services carrying agreed availability and capacity (SLA/SLO) targets. Out of scope: the projects that execute an approved replacement or upgrade (each tracked externally as its own project item) and live incident response for availability outages. Named deliverables: the reconciled solution-asset register and optimization actions, the ranked end-of-support exposure list and disposition, funded replacement/upgrade plans (Issue items) and compensating-control records (Control items) with signed risk acceptances (policy_exception Issues carrying exception_expiry_date, on treatment: accept Risks), the capacity/availability dashboard and corrective plans, and the validated prior-period target package. No upstream workflow feeds this cycle and there is no separate downstream workflow to hand off to — the still-open replacement/upgrade plans, capacity corrective plans, and risk-acceptance expiries (their existing Issue and Risk items, linked to the anchor Control) carry forward as explicit inputs to the next quarterly run of this same workflow.
workflow · Context
Offboarding & Access Revocation
Runs on the existing personnel item. Revoke a leaver access across every in-scope system within the policy window, evidence each revocation, and approve the revocation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Remediation Delivery & Validation
Runs on the existing remediation item. Plan and deliver corrective action, independently validate it against agreed closure criteria, and approve a traceable remediation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Backup & Recovery Testing
Runs on the existing system item. Test recoverability for a system by performing an actual restoration and measuring the result against recovery objectives. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
NIST RMF System Authorization (ATO) Cycle
Runs the seven NIST SP 800-37r2 RMF phases — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — against a single information system to reach and then sustain an authorization-to-operate (ATO) decision. The cycle is anchored on an Audit item created per authorization ("RMF ATO Cycle — <system> <year>", audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the AO decision calendar); the information system itself is enriched as an existing Process item (process_type=security_process). Studio has no System/Asset type, so the RMF-specific facts (FIPS 199 categorization, selected baseline, ATO decision, authorization-termination date) live in the phase documents and on the Audit anchor rather than in dedicated fields. In scope: the defined authorization boundary and its inherited, hybrid, and system-specific controls (existing Control items). Out of scope: enterprise-wide common-control-provider programs and standalone penetration testing, which run as their own engagements and are consumed here only as assessment evidence. Named deliverables: the FIPS 199 categorization memo, the System Security Plan (SSP), the Security Assessment Report (SAR), the Plan of Action & Milestones (POA&M), and the signed ATO letter — assembled into one authorization package for the authorizing official. No upstream workflow feeds this cycle; it originates at Prepare. Downstream it hands off to itself: the Monitor phase's reauthorization triggers re-instantiate this template against the same system, and the Monitor phase's closing export is the authorization record the next cycle's Prepare consumes.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
Control Design Assessment
Runs on the existing control item. Assess whether a control is clearly specified and designed to address its stated risk before deciding what follow-up or testing is appropriate. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Exception Evaluation and Remediation
Runs on the existing control item. Validate a control-test exception, evaluate its scope and implications, determine disposition, and establish accountable remediation where needed. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Remediation Retest and Closure
Runs on the existing control item. Verify remediation readiness, independently retest the changed control, evaluate sustained results, and approve a supported closure decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Walkthrough
Runs on the existing control item. Walk one representative transaction or event through the control to understand actual execution, evidence, handoffs, and changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 Availability Assessment
Design-readiness review of the SOC 2 availability series: capacity management, environmental protections with backup and recovery infrastructure, and recovery plan testing (A1.1–A1.3). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Confidentiality Assessment
Design-readiness review of the SOC 2 confidentiality series: identification and maintenance of confidential information and its secure disposal at end of life (C1.1–C1.2). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Privacy Criteria Assessment
Design-readiness review of the full SOC 2 privacy series: notice and choice, collection through disposal, data subject access and disclosure, and data quality with dispute monitoring (P1.1–P8.1), concluded with dual sign-off on the criteria-bearing final assessment. Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
Employee Offboarding
Run on an existing personnel item using an authorized departure record, access inventory and retention instructions. Produce the Employee Departure Package and hand remaining obligations to HR after IT removal evidence and manager handover review.
workflow · Context
Employee Onboarding
Run on an existing personnel item using signed engagement, screening references and an approved role profile. Produce an Onboarding Readiness Package with IT access evidence for HR, the manager and subsequent access reviews.
workflow · Context
GCP Physical and Environmental Subservice Reliance
Evaluate GCP assurance-report scope, physical and environmental controls, exceptions and user responsibilities; record a bounded reliance decision rather than claiming to operate provider facilities. This customer-side review relies on relevant independent reports, disclosed provider information and customer implementation evidence. It does not operate or certify GCP facility access or environmental safeguards. Preserve each report's permitted-use restrictions.
workflow · Context
Remediation Delivery
Deliver one corrective action against a finding and capture the evidence it produces. Validation and closure approval happen on the finding’s own workflow, where every action raised against it is judged together.
workflow · Context
System ITGC Operation
Operate and evidence the IT general controls on a system: authentication and password configuration, access provisioning and deprovisioning, the periodic user access review, change management (testing, sign-off, logs), and subservice SOC report reliance.
workflow · Context
Annual Policy Review
Runs on the existing policy item. Canonical annual policy review: establish scope, obtain the policy owner and policy team sign-offs, record any required change path, and approve a documented review outcome and next review date. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Domain Oversight and Management Review
Quarterly management review of one process area - the process area's own oversight run. The domain owner reviews the registers the domain operates (systems, tenants, audits), the health and evidence of the operating-process runs, the domain's risks, issues and metrics, and the operation of its controls, then records direction and a dual sign-off. Instantiated once per process area; the operating processes keep their own runs.
workflow · Context
Issue Remediation and Verification
Triage a finding, agree the Remediations that will clear it, then validate and approve the closure of each one before closing the finding itself.
workflow · Context
Policy Change
Runs on the existing policy item. Canonical policy-change governance: scope and propose a controlled change, obtain policy-team approval, publish only the approved version, and close with a traceable document and communication record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Risk Assessment and Treatment Review
Runs on the existing risk item. Assess a risk against current context and evidence, select a supported treatment response, and approve a traceable review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
System and Third-Party Risk Review
Runs on the existing system item. Review system and provider dependencies, assess current risk and control evidence, select response actions, and approve the review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
Interim Operating Effectiveness Testing
Runs on the existing SOX Audit using approved Control-hosted TOD/TOE results and the interim scope. Produces the program coverage and exception register, remaining-period commitments, all-controls auditor handoff and management status communications for year-end roll-forward.
workflow · Context
Period-End Roll-Forward Testing
Runs on the existing SOX Audit using approved interim results and remaining-period commitments. Produces independently reviewed year-end coverage, a separate Year-end Management Inquiry Package and the full-year conclusion for audit reporting and deficiency aggregation.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
Quarterly Board & Audit-Committee GRC Reporting
Runs on the existing standing "Board & Audit-Committee GRC Reporting" governance Process item (process_type=business_process, frequency=quarterly): one workflow instance per quarter attaches to that Process and enriches it (the Process is not created here), and each closed instance is the prior-quarter baseline for the next run. The named deliverable is the quarterly board & audit-committee GRC pack (six-domain narrative deck, Word + PDF, redaction-cleared). It compiles that pack across six domains — risk profile, control health, open issues, regulatory deadlines, audit-plan progress, and SOX posture — computed over one quarter window. In scope: aggregating and synthesizing existing GRC records (Risk, Control, Issue, Audit, and Control-hosted SOX testing workflows) into a board-level narrative, obtaining executive and committee approval, and archiving the decision and action register. Out of scope: performing the underlying risk assessments, audits, or control tests themselves. Consumes two upstream handoff packages: the Enterprise Risk Assessment & Portfolio Oversight Cycle package (risk register, residual scores, appetite positions) and the Audit Report Drafting & Regulatory Compliance Attestation Cycle package (audit-plan status, issued reports, attestation status); there is no downstream workflow — the closed package feeds the next quarterly run of this workflow.
workflow · Context
Risk Appetite Definition & Board Reporting
Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
Policy Exception & Risk Acceptance
Policy Exception & Risk Acceptance as a decision-aware workflow. It carries a waiver from request and justification through risk assessment, compensating controls, time-bound approval, registration with expiry, and re-review so no exception outlives its rationale. The exception IS an Issue item (issue_type: policy_exception) — the workflow runs on it, and the exception register is simply the set of those Issues, queryable by their filterable exception_expiry_date. The affected policy is a Policy item the Issue links to; a granted acceptance also sets treatment: accept on the linked Risk item. In scope: time-bound exceptions/waivers to an existing policy that are risk-accepted for a bounded window. Out of scope: permanent policy-change proposals, which route to the Policy Lifecycle Management workflow (the Policy item's revision process) rather than this waiver workflow. No upstream or downstream workflow feeds or consumes this one; the exception request is the initial input, and recurring-exception patterns are compiled as feedback onto the affected Policy items at close.
workflow · Context
IT Governance Objective Review (COBIT)
Periodic review of selected COBIT 2019 governance and management objectives, run per cycle on an Audit item (audit_type: it_audit; scope = the in-scope objectives; period_start/period_end = the assessment cycle) that the workflow instance attaches to and archives at close. Each in-scope COBIT objective is a Process item (process_type: it_general_control) linked to that Audit, and the review produces named deliverables against it: an evidence register and pre-scored capability sheet, a signed capability profile, a gap table with the benchmark decision, a committed improvement roadmap of Issue initiatives, and the governance board report and dashboard. In scope: the COBIT 2019 objectives selected for this cycle, each with a justified 0-5 target capability level, a named accountable owner, and the review cadence; out of scope: objectives explicitly excluded with recorded rationale. Self-originating: its scope sheet and target profile are supplied as workflow inputs, and it hands off to no distinct downstream workflow — the carry-forward improvement Issues and the archived instance seed its own next cycle.
workflow · Context
Risk & Resilience Framework Governance
Risk & Resilience Framework Governance as a decision-aware workflow. The instance runs on the "Enterprise Risk Management Framework" Process item (process_type: business_process, process_owner = the framework owner, frequency: annual) - created on the first cycle at "Design core ERM framework" and enriched every cycle thereafter, never duplicated; that Process item is the governance register entry, and each governance cycle runs as a workflow instance attached to it, so the at-least-annual cadence is provable from one item's instance history. Working from the organization's context and the ISO 31000 / COSO ERM / DORA reference models - no upstream workflow package feeds it, because this workflow establishes the governance layer - it establishes or refreshes the enterprise risk management framework, extends it for ICT operational resilience and regulated technologies, secures management-body approval and budget, drives implementation across the organization, and runs the at-least-annual review, filling the governance layer the risk-cycle workflows run inside but never establish. The named deliverable is the approved risk & resilience framework package (core ERM design + ICT operational-resilience (DORA) extension + any regulated-technology lifecycle extension), archived at close as durable governance evidence. In scope: the enterprise risk framework, its always-in-scope ICT operational-resilience (DORA) extension, and any regulated-technology (e.g. high-risk AI) extensions to be evaluated. Out of scope: executing the individual risk-cycle workflows (identify / assess / treat / monitor) that run inside this framework - this workflow governs them but does not perform them, and consumes no upstream workflow package. Downstream, the archived framework enables those risk-cycle workflows, which reference it as their governing baseline (the relationship is real but not modeled as a node).
workflow · Context
Code of Conduct & Workforce Accountability Cycle
Code of Conduct & Workforce Accountability Cycle as a decision-aware workflow that runs on an existing ethics Process item ("Ethics & Code of Conduct Program", process_type: business_process, frequency: annual): each annual cycle is a workflow instance attached to that Process, and the archived instances on it ARE the ethics register - version history plus the open-deviation log. The code of conduct and the rules of behavior are Policy items (policy_type: policy and procedure) enriched each cycle - never recreated - and the tone-at-the-top and acknowledgment Controls (UC-GOV-04, UC-GOV-07) are linked to the Process via item relationships. The cycle reissues the code and rules of behavior, secures leadership adoption, communicates expectations to personnel and business partners, gates access on acknowledgment, and evaluates adherence - routing violations through the documented disciplinary process and remediating deviations timely, with deviations and violations recorded as Issue items carrying the full remediation lifecycle. Named deliverables: the reissued code of conduct and rules of behavior (Policy items plus redline/change summary), the leadership adoption decision, the acknowledgment coverage report with access-gating evidence, the deviation and violation inventory (Issues), the disciplinary and remediation outcomes, and the archived self-contained cycle evidence package. In scope: one annual accountability cycle (a full reissue or an update-driven re-acknowledgment) covering all in-scope personnel and the business-partner populations bound by the code. Out of scope: the ethics-hotline intake that feeds reported concerns - an input, not a step here. No upstream workflow is required to start the cycle; it is triggered by its annual cadence or by a material change to the code or rules of behavior. Downstream, the operational access-provisioning system consumes this cycle's acknowledgment gate - the workflow's terminal handoff - before it grants access.
workflow · Context
Technology Investment & Project Risk Governance
Technology Investment & Project Risk Governance as a decision-aware checkpoint graph, run as a recurring workflow instance attached to the existing Process item for the technology-investment / portfolio-governance process (process_type: business_process) — each quarterly board cycle enriches that standing process record rather than creating a new one. In the cycle the investment board refreshes its criteria, scores and prioritizes the technology and innovation portfolio, routes the annual capital-planning leg that allocates security funding to the risk strategy, monitors in-flight value and reprioritizes or terminates where value is not realized, and enforces security-risk sections in every project gate with ERM-linked artifacts. In scope: the quarterly technology investment-board review (always), the annual capital-planning and security-budget leg (when the funding and staffing envelope must be set or re-planned this cycle), and every project stage gate falling due. Out of scope: individual project execution and delivery mechanics and day-to-day security operations. The cycle consumes the ERM cyber-risk register (Risk items, category: cyber_security) and the approved program business cases as standing inputs, and produces a board decision record and evidence pack as its named deliverable. There is no downstream workflow hand-off, so cross-references are recorded as linked records (Issue ↔ Risk) rather than routed onward; the scored portfolio, in-flight programs, and stage-gated projects have no native item type and live as step documents.
workflow · Context
Strategic Context & Objectives Alignment Cycle
Strategic Context & Objectives Alignment Cycle as a decision-aware workflow. Anchor: this recurring governance cycle runs on and enriches the existing "Strategic Planning & Objectives Alignment" Process item (process_type business_process, annual frequency) that represents the strategy-refresh process itself; where no such convention item is seeded it runs standalone with every output attached to the workflow instance. No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger, run annually or on an event-driven change such as an acquisition, a new market or regulation, a material risk-profile shift, or a significant incident; its only prior-cycle input is this workflow's own previous run, archived at close-and-archive. It refreshes the mission statement and stakeholder register, builds a bidirectional objectives-and-dependency map, communicates that context to risk-scoping owners, realigns and cascades strategy into a published and monitored roadmap, and closes by documenting mission-essential business processes as Process items with their information-protection needs as the approved basis for risk-assessment scoping. Named deliverables: the refreshed mission statement (DOCX) and stakeholder register (XLSX), the objectives-and-dependency map, the published context package and change summary, the strategy realign-or-reaffirm decision, the realigned enterprise and technology strategy (realign branch), the cascaded objectives and published roadmap, the mission-essential Process definitions, and the archived cycle record. In scope: the mission and stakeholder context refresh, strategy realignment and objective cascade, and the mission-essential process and risk-scoping definitions. Out of scope: executing the risk assessment itself. Downstream handoff: the exported cycle record and the approved mission-essential Process items are the scoping basis consumed by the Enterprise risk-assessment cycle.
workflow · Context
Data Governance Council Operations
Data Governance Council Operations as a decision-aware workflow. Each quarterly cycle runs as one workflow instance attached to the existing UC-GOV-20 Control item (data governance council oversight; domains=governance_policy_oversight, frequency=quarterly) — it enriches that Control as its execution record and never creates a governing body. It validates the chartered council's charter and membership, runs the annual policy and lifecycle-standards review when due, compiles data-quality and integrity metrics, reviews and approves data-sharing and matching agreements, convenes the council with recorded minutes, and reports data governance status at the defined interval. Upstream, it consumes the prior cycle's archived governance record — the council and data-integrity-board charters (Policy items, policy_type: charter) and membership rosters, the current data-governance policy and data-lifecycle standards library (Policy items), the prior minutes and status report, and the open action-item register (Issue items linked to the Control). Named deliverables: the data-quality and integrity dashboard, the data-management oversight summary, the chair-approved council (and integrity board) minutes, the per-agreement dispositions, and the data-governance status report; the annual branch adds the refreshed policy and standards redlines and the charter and roster amendments. In scope each quarterly cycle: the named business units and data domains, the data governance council (always), and the data integrity board wherever data-matching (Privacy Act computer matching) or new data-sharing requires its review; a metrics-only cycle need not convene the integrity board. Out of scope: bodies and data domains not named in the cycle's scope. Downstream the workflow is self-contained — no separate workflow depends on it — but it chains cycle to cycle: this cycle's archived governance record, filed with the status report, is the next quarterly instance's primary input.
workflow · Context
Enterprise Risk Treatment Operations Cycle
Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.
workflow · Context
Subservice Organization & Third-Party Personnel Oversight
Subservice Organization & Third-Party Personnel Oversight as a checkpoint graph. Anchor: each run enriches the existing subservice-organization **Vendor** register entry for one provider - the workflow instance and every step document attach to it, and it is never recreated (initial vendor selection and onboarding due diligence are out of scope). In scope: the subservice organizations and third-party suppliers whose services support user-entity control objectives or whose personnel access the organization's systems or data - reconciling and enriching their Vendor register entries, verifying subservice and personnel-security contract terms, reviewing assurance (SOC) reports and mapping complementary user-entity controls (CUECs) to internal Control items, routing exceptions to tracked Issue items, collecting third-party personnel-compliance evidence, monitoring vendor performance, and running the quarterly issue follow-up through to closure. Out of scope: initial vendor selection and onboarding due diligence, and the organization's own internal personnel controls. Upstream: no workflow feeds it - it is built from the existing Vendor register, the prior cycle's archived vendor file, open Issue items, and the internal Control inventory, plus contracts, SOC reports, and performance data uploaded as evidence. Downstream: self-contained - no single workflow consumes its output; the archived, auditor-ready vendor file is the durable evidence record. It runs on the annual per-vendor cycle with quarterly issue follow-up.
workflow · Context
Personnel Screening, Agreements & Sanctions Administration
Runs on the existing "Personnel Security Administration" Process item (process_type: security_process; process_owner: the HR Personnel Security Partner): each cycle is one workflow instance attached to that Process - enriching the standing process, never creating a duplicate - and on the disciplinary track the violation-case Issue it opens becomes the cycle's second anchor, linked back to that Process. A modular, decision-aware workflow: it designates position risk, runs proportional background verification for new hires, role changes, and the annual high-risk rescreen sweep, produces and retains the signed employment security and confidentiality agreements required before access, and - when a policy violation is reported - runs the graduated disciplinary process through sanction determination, PS-8 notification, and retention. It originates on its own HR triggers (no upstream workflow feeds it) and hands access provisioning and revocation to the downstream Joiner-Mover-Leaver Access Lifecycle workflow rather than performing them here. Named deliverables per cycle: the position-risk designation memo and derived screening set, the background-verification packet, the signed employment security and confidentiality agreements plus security-bearing position description, the violation-case Issue, the sanction documentation and PS-8 notification record, the awareness and control-improvement feedback Issues, and the archived cycle record. In scope: one personnel-security trigger per cycle - a single new hire, role change, annual high-risk rescreen, or material agreement re-signature on the screening-and-agreements track, or one reported policy violation on the disciplinary track; a role change that also surfaces a violation is run as two separate cycles.
workflow · Context
Vendor Due Diligence & Contracting Gate
Vendor Due Diligence & Contracting Gate as a modular, decision-aware workflow. Anchor: the vendor's register entry — the Vendor item (slug: vendor). For a net-new engagement the gate creates the Vendor item and populates its tier, data_classification, business_owner, and risk_owner; for a renewal it enriches the existing Vendor item rather than duplicating it (enrich, never recreate). This is the first-line pre-contract gate the vendor-management office runs for every new engagement or renewal - tiering criticality, running proportionate due diligence into the vendor due-diligence report, documenting the risk-acceptance decision and any risk-reducing sourcing conditions, binding the contract to required security, privacy, and regulatory clauses, authorizing the specific information exchange before access begins, and - where personal data is involved - obtaining the signed written privacy commitments and scheduling compliance monitoring and incident-response routing. In scope: pre-contract due diligence, risk acceptance, and contract execution for one vendor engagement, ending with the Vendor item enrolled in monitoring (Vendor.monitoring_status = enrolled). There is no upstream workflow — the engagement trigger (a new prospective vendor or a renewal) is its own entry point. Downstream handoff: the archived gate record exported at close is the handoff package the ongoing third-party risk monitoring / vendor oversight lifecycle picks up to sustain the scheduled compliance checks and incident routing; that linkage is a prose handoff of live controls on the same Vendor item, not a triggered downstream node.
workflow · Context
Third-Party Risk Program & Vendor Oversight Cycle
A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item "Third-Party / Vendor Risk Management" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.
workflow · Context
Enterprise Risk Assessment & Portfolio Oversight Cycle
Second-line ERM oversight cycle. Each run is anchored to a cycle Audit item created for the period (audit_type: operational, scope = the assessment boundary, period_start/period_end = the cycle window, report_date = the approval date); the workflow instance attaches to it as the durable audit trail, and the enterprise Risk items are the register it assesses and updates in place. Establish the assessment context (scope, criteria, appetite, scoring calibration), identify risks, score inherent and residual severity, select responses, publish the portfolio view, and route the package through disposition and governance approval. In scope: enterprise-level risk identification, assessment, response selection, and portfolio reporting for the current cycle. Out of scope: defining the board-approved risk appetite statement itself and preparing the board reporting deck, which are handled by downstream workflows. Consumes the prior-cycle risk-register handoff package (the existing Risk items plus the linked register document) from the Enterprise Risk Register Lifecycle workflow, and hands its named deliverables — the residual portfolio view (dashboard), the risk-movement narrative, and the approved assessment package — to the Risk Appetite Definition & Board Reporting and Quarterly Board & Audit-Committee GRC Reporting workflows.
workflow · Context
Vendor Offboarding & Secure Termination
Vendor Offboarding & Secure Termination as a decision-aware workflow triggered on a relationship termination. It runs on the vendor's existing Vendor register item - the offboarding enriches that record, it never creates a duplicate: the run marks the Vendor `monitoring_status: exited` and stamps `contract_end_date`, and where the vendor's risk is registered it links to the existing third-party Risk item (`category: third_party`). In scope: executing one vendor's contractual exit end to end - inventorying the vendor's access, data, and dedicated components; containing access immediately on for-cause exits; transitioning each service to its successor; revoking every credential; verifying data return or destruction; disposing of internal-side components using defined techniques; and retaining the post-relationship evidence. Out of scope: the underlying contract-termination or renewal business decision and any separately-governed affiliate contracts. Initial inputs are the termination trigger and effective date, the vendor's contractual exit provisions (master agreement, data processing addendum, exit plan) - which also carry the data-disposition and evidence-retention clauses consumed downstream - and the existing Vendor register item with its risk tier; there is no upstream workflow. The named deliverable is the retained, audit-standing termination evidence package assembled at compile-termination-evidence-and-retain; the workflow is terminal - close-and-archive exports the run and hands off nothing downstream.
workflow · Context
Risk & Control Self-Assessment (RCSA) Program
Risk & Control Self-Assessment (RCSA) Program as a modular, decision-aware workflow. Each wave runs on its own Audit item — created per wave (audit_type: operational; period_start/period_end = the wave window; report_date = the risk-committee date) — with the workflow instance attached to that item and the wave's questionnaires, attested returns, and calibration record kept inside the run. Each wave rebuilds the assessment universe from the existing Process, Risk, and Control items and their owners (enriching them, never recreating them), issues rating questionnaires to named control and process owners, collects attested self-assessments with structured exception capture, chases completeness, subjects the results to second-line challenge and calibration, aggregates a residual-risk view across units, updates the risk register's residual ratings, and routes self-identified issues to remediation and exceptions to time-bound acceptance before the results reach the risk committee. In scope: first-line self-assessment of in-scope business units and shared functions against their own risks and controls. Out of scope: independent testing/audit of those controls, and the remediation and formal risk-acceptance of what the wave surfaces, which are handed off downstream to the Finding Remediation & Action-Plan Monitoring (deficiencies), Policy Exception & Risk Acceptance (risk-acceptances/waivers), and Quarterly Board & Audit-Committee GRC Reporting (the wave report) workflows.
workflow · Context
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
Control Library Lifecycle
One control, one record: intake, author, classify, link, publish, review, retire — the library that audit RCM and SOX scoping read from.
workflow · Context
Issue Triage & Disposition
Runs on the existing issue item. Substantiate a reported issue, assess its severity and cause, select a governed disposition, and approve the triage record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Risk Appetite & Tolerance Calibration
Runs on the existing risk item. Set or recalibrate the appetite statement and tolerance thresholds for a risk, test the current position against them, and approve the escalation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Enterprise Risk Register Lifecycle
Enterprise Risk Register Lifecycle as a decision-aware workflow. This is a standalone recurring instance (quarterly or annual) that runs against the existing Risk item population — the enterprise risk register itself — enriching those Risk items in place rather than recreating a register: per-risk results are written onto the individual Risk items, and cycle-level deliverables attach to the workflow instance's steps. In scope: maintaining the register across the confirmed entities, business units, and risk-taxonomy categories for this cycle — intake and deduplication of new risks, Three-Lines ownership, control and assurance mapping, KRIs, periodic review and escalation, and retirement. Out of scope: any entity, unit, or category not named in this cycle's confirmed scope. It consumes the candidate-risk handoff package from the upstream Risk Register Intake workflow and hands its maintained register, residual positions, and escalations to two downstream workflows — Enterprise Risk Assessment & Portfolio Oversight Cycle (the maintained register, the concentration and correlation flags, and the residual positions) and Risk Appetite Definition & Board Reporting (the above-appetite entries, the escalations, and the acceptances) — rather than duplicating repeated work.
workflow · Context
ESG-Related Risk Materiality & Integration
ESG-Related Risk Materiality & Integration as a decision-aware workflow. Each cycle runs on the existing portfolio-level ESG Risk item (a Risk with category: esg — e.g. "ESG / sustainability risk — enterprise"): it enriches that umbrella entry and the ESG-tagged slice of the Risk register (Risk items tagged category: esg / taxonomies: esg_sustainability) rather than recreating them, and fans per-topic detail out onto the individual Risk items it creates or updates for each impact, risk, and opportunity (IRO). In scope: assessing ESG-related risks across the confirmed environmental, social, and governance topics, entities, and value-chain boundary for this cycle — defining the ESG risk universe (impacts, risks, opportunities), engaging affected stakeholders and information users, assessing double materiality and prioritizing the material topics, mapping controls and management responses, defining KRIs and disclosure metrics, and assembling disclosure inputs. Its named deliverables are the double-materiality assessment (the ranked material topic set with a materiality matrix), the control/response and assurance mapping, the disclosure metrics and leading KRIs, and the framework-mapped disclosure index (ESRS/CSRD, ISSB S1/S2, GRI, SEC climate). Out of scope: any ESG topic, entity, or business unit not named in this cycle's confirmed scope, and the drafting of the external sustainability report itself. It consumes the enterprise risk portfolio and residual positions from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its material ESG topics, KRIs, and disclosure inputs to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Framework Adoption & Cross-Mapping
Adopt or refresh a security/compliance framework (for example NIST CSF 2.0, ISO/IEC 27001:2022, or SOC 2) by scoping the target framework, rating the current profile, defining the target profile, crosswalking requirements to existing controls and adjacent frameworks, prioritizing gaps, and maintaining a live mapping table. The workflow instance runs on an Audit item created at the start of each adoption cycle (audit_type: readiness, or compliance) — its scope/period fields carry the assessment boundary and cycle window, and every step document versions against it. No upstream workflow feeds this one; it consumes the organization's own existing inventory: the risk register (Risk items), the control library / RCM (Control items and their Risk links), the in-scope Process inventory, and any prior Audit items for this or adjacent frameworks. Named deliverables: the framework mapping table (the crosswalk), the risk-ranked prioritized gap list, the coverage/gap dashboard, and the versioned adoption package. In scope: profile construction, crosswalk mapping, gap prioritization, and the closure disposition. Out of scope: authoring the policies and designing the new controls the gaps demand — those are handed off downstream to TWO workflows, Policy Lifecycle Management (policy-driven gaps) and Control Design (control-build gaps).
workflow · Context
Incident Management Lifecycle
Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Personal Data Quality & De-identification
Personal Data Quality & De-identification runs as a recurring operate cycle attached to the existing Control for personal-data quality & de-identification (framework gdpr/hipaa/ccpa/nist-800-53, domain data_protection_privacy): each period is a workflow instance that enriches that Control's operating record — never a new Control. The cycle consumes the data map / RoPA, the data-quality ruleset and retention schedule (Policy items), the individual correction-request queue, the disclosure log and the recipient/processor Vendor register, and the de-identification policy; it checks PII accuracy, relevance, timeliness, and completeness, corrects or deletes failing records and notifies downstream recipients under GDPR Art. 19, adjudicates individual correction requests within statutory deadlines, and de-identifies datasets that do not require full identifiers. It produces the exception register (exception Issue items), the corrected-and-deleted set, the recipient correction/deletion notices, and the de-identification and residual-risk reports; systemic findings hand off to the internal privacy backlog as Issue items. This is a terminal operate cycle — the archived, regulator-ready cycle record is the deliverable, not a handoff package for a named downstream workflow.
workflow · Context
Privacy Safeguards & Notice Management
Privacy Safeguards & Notice Management as a decision-aware cycle that runs as a workflow instance attached to the standing "Privacy Program" Process item (process_type: business_process, process_owner: the privacy officer) — one archived instance per period is the cycle file. Each run refreshes the privacy requirements inventory, confirms PII-protection accountability over the PII stores (modeled as processing-activity Process items), verifies administrative, technical, and physical safeguards against data volume and sensitivity (the safeguard set is the Control items with control_category administrative|technical|physical and framework gdpr|ccpa|hipaa protecting each store), remediates gaps as tracked Issues, and authors, publishes, and version-retains the privacy notices and registrations (modeled as Policy items) kept accurate to actual processing. In scope: the periodic privacy program cycle over the confirmed PII stores, their safeguard control set, and the published notice and registration population; every run reconciles the affected notices to actual processing — a cycle that skips notice reconciliation is a different workflow. No upstream or downstream workflow feeds or consumes this cycle; its inputs are the organization's own privacy program records, and open remediation, treatment expiries, and deferred drift carry forward as open Issues that seed the next cycle's intake.
workflow · Context
Privacy Breach Assessment & Notification
Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
DPIA / Privacy Impact Assessment
GDPR Article 35 data protection impact assessment as a decision-aware workflow, run on the existing Process item (process_type=business_process) that represents the processing activity under assessment — the Process item doubles as the AssureSwarm proxy for the activity's records-of-processing (RoPA) entry, and the instance enriches it rather than creating a duplicate. It draws on upstream evidence — the RoPA extract, the data inventory and data-flow map, the Article 28 processor arrangements and transfer impact assessment from vendor due diligence, and the security risk assessment for the hosting systems — and moves the activity from screening, through necessity and proportionality and privacy-risk treatment, to a residual-risk decision with Article 36 prior consultation where needed and DPO sign-off. The named deliverable is the signed, versioned DPIA package (or, on the screened-out path, a defensible screening memo), registered against the Process item with tracked mitigation actions; close-and-archive hands that package off to records-of-processing maintenance. In scope: one processing activity (or a set of similar operations with comparable risks per Article 35(1)) from screening through sign-off; out of scope: the related workflows it draws on or feeds — vendor due diligence for new processors, transfer impact assessment for third-country transfers, security risk assessment for the hosting systems, and the records-of-processing maintenance that absorbs the outcome.
workflow · Context
Privacy Program Operations (Consent, Complaints & Sharing)
Runs the standing **Privacy Program Operations** process — an existing operational Process item (process_type=operational, process_owner = the privacy officer) — on a recurring cycle: this workflow instance attaches to that Process and IS the cycle record. It enriches what already exists rather than recreating it: the anchor Process, the in-scope RoPA processing-activity Process items, the privacy Control and Policy items, and the still-open Issues carried forward from prior cycles. Three parallel streams run inside the cycle — reconcile consent and preferences against processing activities, resolve privacy complaints with an accounting of disclosures, and govern data-sharing agreements against actual flows — each consuming verifiable extracts (consent-platform events, the disclosure log, integration/transfer logs) and producing named deliverables: the consent reconciliation report, the complaint register (Issue items), executed agreement renewals with any legal-approved interim risk treatments, and the cycle metrics pack, before the cycle is archived to its retention schedule. Self-contained recurring cycle; the approved metrics pack informs downstream privacy governance / committee reporting.
workflow · Context
Annual ICFR Scoping & Risk Assessment
Runs on the fiscal year’s existing SOX Audit, using financial balances, prior-year RCM and deficiency history, business changes, and the approved IA plan. Produces the Fiscal Year Audit Scope Memo, Risk & Control Matrix, approved workplan, kickoff records and recipient-specific annual communications for process walkthroughs and control testing.
workflow · Context
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
Quarterly 302/906 Sub-Certification Cascade
Quarterly 302/906 sub-certification as a modular, decision-aware workflow: it maintains the certifier hierarchy, refreshes the questionnaire for new systems, reorgs, known control issues, and pending deficiencies, launches the tiered cascade, tracks completion and cures gaps at the cutoff, triages exceptions and qualifications with escalation to the disclosure committee where material, summarizes the population for principal-officer 302/906 sign-off, and archives the certification evidence with the period's support. The instance runs against a campaign-record Audit item created for the quarter (audit_type: compliance; period_start/period_end = the quarter; scope = the in-scope entity and process population), enriching that one record — every questionnaire form, certification register, decision form, dashboard, and attestation package hangs off it and the run's own instance is the audit trail. It consumes the in-scope Process items (each carrying its process_owner) and the open deficiency Issue log, originates on its own recurring quarterly cadence with no upstream handoff, and hands its deficiencies downstream as linked Issue items into the SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows. In scope: the quarter's in-scope entities and processes per the current consolidation scope, from process-owner sub-certification through principal-officer 302/906 sign-off and archival, back-planned from the SEC filing date. Out of scope: the officers' external SEC filing mechanics, and the deficiency, year-end aggregation, and board reporting handled by the downstream SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows this cascade routes into.
workflow · Context
Control Interim Testing Record
Runs on the existing control item. Test a defined interim-period population using a documented sampling and attribute plan, then record exceptions and a bounded conclusion. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Period-End Roll-Forward / Rollover Testing
Runs on the existing control item. Bridge an approved interim control test through period end by assessing change, remaining occurrences, incremental evidence, and unresolved exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Control Testing
Runs on an existing SOX-applicable Control under a sox-testing template. SAMPLE reviews history, attributes and reproducible selection; TEST reviews evidence, exceptions and the approved result artifact. Keep fiscal year on Workflow.customFields.sox.fiscalYear and hand the published result to the SOX program.
workflow · Context
Process Walkthrough & Design Assessment
Runs on the existing process item. Perform a SOX process walkthrough, update the ICFR narrative and control mapping, and document design observations for management follow-up. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Deficiency Evaluation & Committee
Runs on the existing audit item. Evaluate SOX control deficiencies individually and in aggregate, obtain management challenge, and govern committee communication and disposition. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Deficiency Remediation
SOX Deficiency Remediation carries one control deficiency's full lifecycle — grade, root cause, remediation, validation, and closure. The workflow runs on the deficiency **Issue item** it opens at grading — `issue_type` set to the exact SOX grade (deficiency / significant_deficiency / material_weakness) and `severity` on the mapped AssureSwarm scale — linked to the affected Control(s), the source Control-hosted SOX testing workflow (template kind: sox-testing), and the current-year SOX audit (Audit, `audit_type: sox_testing`); the remediation actions and the validation retest live as steps on this Issue's own workflow. In scope: a single deficiency triggered by a failed test or unresolved exception. It **consumes** the concluded, reviewed failed-test workpaper handoff package owned upstream (SOX Key Control TOD/TOE Test and SOX ITGC Testing) and **hands off** the closed-or-carried deficiency outcome — with its intact severity history and any triggered communication obligations — to Quarterly Board & Audit-Committee GRC Reporting, which aggregates the full deficiency population into the period's ICFR conclusion and audit-committee materials. It exchanges handoff packages with those related workflows rather than duplicating their work.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control TOD/TOE Test
Runs directly on an existing SOX-applicable Control for the fiscal year, using the approved walkthrough, scope, methodology and evidence. Produces an independently approved TOD memo before sampling, period-specific TOE results and reviewed exception evidence for interim/year-end assessment and deficiency remediation. Require that the Control fields.sox_applicable value is the literal boolean true; use Workflow.customFields.sox.fiscalYear for the cycle. TOD/TOE test periods remain step-level facts.
workflow · Context
SOX Process Walkthrough
Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control Operation (Close Cycle)
Runs against the existing Financial Close **Process** item (process_type: financial_reporting, monthly) — one workflow instance per close period that operates that period's SOX key controls and is archived when the control owner's sub-certification closes the period, as the period's durable, control-indexed evidence trail; it enriches the standing Process and Control records, never recreating them. Consumes upstream: the in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) produced by the *Annual ICFR Scoping & Risk Assessment* workflow and linked to this Financial Close Process — plus the prior period's carry-forward **Issue** items (aged reconciling items, approved carryovers). In scope: the close-cycle key controls operating each period — account reconciliations, management review controls, and journal-entry approval — scoped against the period-end close boundary. Named deliverables: the period IPE log, the signed account reconciliations, the completed MRC checklists, the journal-entry approval register, the control-indexed period evidence package, and the control owner's signed sub-certification (supporting the officers' Section 302 certification). Downstream handoff: the archived evidence package and control execution log stand as the sampling population for the *SOX Key Control TOD/TOE Test*; escalated potential deficiencies continue in the *Year-End Deficiency Aggregation & Severity Evaluation* (deficiency-evaluation) track. Out of scope: deficiency severity evaluation and TOD/TOE testing themselves, both of which consume this cycle's archived evidence.