Logging, Monitoring & Detection
377 records. Direct records match this topic; 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 · Context
A003 — Limit AI agent data access
Limit AI agent data access
control · Context
A004 — Protect IP & trade secrets
Protect IP & trade secrets
control · Context
A005 — Prevent cross-customer data exposure
Prevent cross-customer data exposure
control · Context
B001 — Third-party testing of adversarial robustness
Third-party testing of adversarial robustness
control · Context
B007 — Enforce user access privileges to AI systems
Enforce user access privileges to AI systems
control · Context
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Context
C008 — Monitor AI risk categories
Monitor AI risk categories
control · Context
C010 — Third-party testing for harmful outputs
Third-party testing for harmful outputs
control · Context
C011 — Third-party testing for out-of-scope outputs
Third-party testing for out-of-scope outputs
control · Context
C012 — Third-party testing for customer-defined risk
Third-party testing for customer-defined risk
control · Context
D002 — Third-party testing for hallucinations
Third-party testing for hallucinations
control · Context
D004 — Third-party testing of tool calls
Third-party testing of tool calls
control · Context
E009 — Monitor third-party access
Monitor third-party access
control · Context
E015 — Log AI system activity
Log AI system activity
control · Context
DSS02 — Managed Service Requests and Incidents
Managed Service Requests and Incidents
control · Context
DSS03 — Managed Problems
Managed Problems
control · Context
DSS05 — Managed Security Services
Managed Security Services
control · Context
P7 — The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
control · Context
DORA-Art17-23 — ICT-related incident management, classification and reporting
ICT-related incident management, classification and reporting
control · Context
DORA-Art24-27 — Digital operational resilience testing (incl. threat-led penetration testing)
Digital operational resilience testing (incl. threat-led penetration testing)
control · Context
AIA-Art12 — Record-keeping / logging (high-risk)
Record-keeping / logging (high-risk)
control · Context
AIA-Art19 — Automatically generated logs — provider retention of high-risk system logs (minimum six months)
Automatically generated logs — provider retention of high-risk system logs (minimum six months)
control · Context
AIA-Art72 — Post-market monitoring by providers of high-risk AI systems
Post-market monitoring by providers of high-risk AI systems
control · Context
GDPR-Art32 — Security of processing
Security of processing
control · Context
GDPR-Art33 — Notification of a personal data breach to the supervisory authority
Notification of a personal data breach to the supervisory authority
control · Context
GDPR-Art44-49 — International transfers of personal data
International transfers of personal data
control · Context
HIPAA-164.312(a) — Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
control · Context
HIPAA-164.312(b) — Audit controls recording activity in systems with ePHI
Audit controls recording activity in systems with ePHI
control · Context
A.5.15 — Access control
Access control
control · Context
A.5.16 — Identity management
Identity management
control · Context
A.5.17 — Authentication information
Authentication information
control · Context
A.5.18 — Access rights
Access rights
control · Context
A.5.25 — Assessment and decision on information security events
Assessment and decision on information security events
control · Context
A.5.26 — Response to information security incidents
Response to information security incidents
control · Context
A.5.28 — Collection of evidence
Collection of evidence
control · Context
A.5.7 — Threat intelligence
Threat intelligence
control · Context
A.5.8 — Information security in project management
Information security in project management
control · Context
A.6.3 — Information security awareness, education and training
Information security awareness, education and training
control · Context
A.6.8 — Information security event reporting
Information security event reporting
control · Context
A.8.12 — Data leakage prevention
Data leakage prevention
control · Context
A.8.13 — Information backup
Information backup
control · Context
A.8.14 — Redundancy of information processing facilities
Redundancy of information processing facilities
control · Context
A.8.15 — Logging
Logging
control · Context
A.8.16 — Monitoring activities
Monitoring activities
control · Context
A.8.17 — Clock synchronization
Clock synchronization
control · Context
A.8.18 — Use of privileged utility programs
Use of privileged utility programs
control · Context
A.8.2 — Privileged access rights
Privileged access rights
control · Context
A.8.22 — Segregation of networks
Segregation of networks
control · Context
A.8.3 — Information access restriction
Information access restriction
control · Context
A.8.4 — Access to source code
Access to source code
control · Context
A.8.6 — Capacity management
Capacity management
control · Context
31000-FW2 — Integration
Integration
control · Context
31000-P1 — Integrated
Integrated
control · Context
A.6.2.4 — AI system verification and validation
AI system verification and validation
control · Context
A.6.2.5 — AI system deployment
AI system deployment
control · Context
A.6.2.6 — AI system operation and monitoring
AI system operation and monitoring
control · Context
A.6.2.8 — AI system recording of event logs
AI system recording of event logs
control · Context
AC-16 — Security and Privacy Attributes
Security and Privacy Attributes
control · Context
AC-2 — Account Management
Account Management
control · Context
AC-24 — Access Control Decisions
Access Control Decisions
control · Context
AC-25 — Reference Monitor
Reference Monitor
control · Context
AC-3 — Access Enforcement
Access Enforcement
control · Context
AC-4 — Information Flow Enforcement
Information Flow Enforcement
control · Context
AC-5 — Separation of Duties
Separation of Duties
control · Context
AC-6 — Least Privilege
Least Privilege
control · Context
AT-2 — Literacy Training and Awareness
Literacy Training and Awareness
control · Context
AT-3 — Role-based Training
Role-based Training
control · Context
AU-10 — Non-repudiation
Non-repudiation
control · Context
AU-11 — Audit Record Retention
Audit Record Retention
control · Context
AU-12 — Audit Record Generation
Audit Record Generation
control · Context
AU-13 — Monitoring for Information Disclosure
Monitoring for Information Disclosure
control · Context
AU-14 — Session Audit
Session Audit
control · Context
AU-16 — Cross-organizational Audit Logging
Cross-organizational Audit Logging
control · Context
AU-2 — Event Logging
Event Logging
control · Context
AU-3 — Content of Audit Records
Content of Audit Records
control · Context
AU-4 — Audit Log Storage Capacity
Audit Log Storage Capacity
control · Context
AU-5 — Response to Audit Logging Process Failures
Response to Audit Logging Process Failures
control · Context
AU-6 — Audit Record Review, Analysis, and Reporting
Audit Record Review, Analysis, and Reporting
control · Context
AU-7 — Audit Record Reduction and Report Generation
Audit Record Reduction and Report Generation
control · Context
AU-8 — Time Stamps
Time Stamps
control · Context
AU-9 — Protection of Audit Information
Protection of Audit Information
control · Context
CA-7 — Continuous Monitoring
Continuous Monitoring
control · Context
CP-10 — System Recovery and Reconstitution
System Recovery and Reconstitution
control · Context
CP-11 — Alternate Communications Protocols
Alternate Communications Protocols
control · Context
CP-12 — Safe Mode
Safe Mode
control · Context
CP-13 — Alternative Security Mechanisms
Alternative Security Mechanisms
control · Context
CP-3 — Contingency Training
Contingency Training
control · Context
CP-4 — Contingency Plan Testing
Contingency Plan Testing
control · Context
CP-6 — Alternate Storage Site
Alternate Storage Site
control · Context
CP-7 — Alternate Processing Site
Alternate Processing Site
control · Context
CP-8 — Telecommunications Services
Telecommunications Services
control · Context
CP-9 — System Backup
System Backup
control · Context
IA-12 — Identity Proofing
Identity Proofing
control · Context
IA-4 — Identifier Management
Identifier Management
control · Context
IA-5 — Authenticator Management
Authenticator Management
control · Context
IA-6 — Authentication Feedback
Authentication Feedback
control · Context
IR-4 — Incident Handling
Incident Handling
control · Context
IR-5 — Incident Monitoring
Incident Monitoring
control · Context
IR-7 — Incident Response Assistance
Incident Response Assistance
control · Context
PM-13 — Security and Privacy Workforce
Security and Privacy Workforce
control · Context
RA-10 — Threat Hunting
Threat Hunting
control · Context
RA-2 — Security Categorization
Security Categorization
control · Context
RA-3 — Risk Assessment
Risk Assessment
control · Context
RA-9 — Criticality Analysis
Criticality Analysis
control · Context
SC-15 — Collaborative Computing Devices and Applications
Collaborative Computing Devices and Applications
control · Context
SC-16 — Transmission of Security and Privacy Attributes
Transmission of Security and Privacy Attributes
control · Context
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Context
SC-26 — Decoys
Decoys
control · Context
SC-3 — Security Function Isolation
Security Function Isolation
control · Context
SC-30 — Concealment and Misdirection
Concealment and Misdirection
control · Context
SC-32 — System Partitioning
System Partitioning
control · Context
SC-34 — Non-modifiable Executable Programs
Non-modifiable Executable Programs
control · Context
SC-35 — External Malicious Code Identification
External Malicious Code Identification
control · Context
SC-38 — Operations Security
Operations Security
control · Context
SC-41 — Port and I/O Device Access
Port and I/O Device Access
control · Context
SC-42 — Sensor Capability and Data
Sensor Capability and Data
control · Context
SC-43 — Usage Restrictions
Usage Restrictions
control · Context
SC-44 — Detonation Chambers
Detonation Chambers
control · Context
SC-46 — Cross Domain Policy Enforcement
Cross Domain Policy Enforcement
control · Context
SC-48 — Sensor Relocation
Sensor Relocation
control · Context
SC-49 — Hardware-enforced Separation and Policy Enforcement
Hardware-enforced Separation and Policy Enforcement
control · Context
SC-50 — Software-enforced Separation and Policy Enforcement
Software-enforced Separation and Policy Enforcement
control · Context
SC-51 — Hardware-based Protection
Hardware-based Protection
control · Context
SC-6 — Resource Availability
Resource Availability
control · Context
SC-7 — Boundary Protection
Boundary Protection
control · Context
SI-4 — System Monitoring
System Monitoring
control · Context
NIST-AGI-01 — Distinct agent identities and identity boundaries
The concept paper explores how to identify software and AI agents, distinguish them from humans, and select identity metadata and boundaries appropriate to the agent and task.
control · Context
NIST-AGI-02 — Agent authentication and credential lifecycle
The paper asks what constitutes strong agent authentication and how keys are issued, updated, and revoked; workload identity and identity lifecycle standards are among the approaches considered.
control · Context
NIST-AGI-03 — Context-sensitive authorization and least privilege
The paper asks how zero trust, changing agent context, aggregated data sensitivity, least privilege, and proof of authority for a specific action can inform agent authorization.
control · Context
NIST-AGI-04 — Delegated authority and human accountability
The project explores linking agents to the users on whose behalf they act, with delegation controls and a binding between agent identity and human authorization.
control · Context
NIST-AGI-05 — Verifiable agent action logs and authorization traceability
The paper asks how agent actions and intent can be logged in a verifiable, tamper-resistant way and traced back to human authorization; visibility includes actions, data, and outcomes.
control · Context
NIST-AGI-07 — Prompt provenance and data-flow tracking
The proposed project explores tracking the provenance of user prompts and input data so that risk assessments and policies can take those sources into account when deciding whether an agent may act.
control · Context
NIST-TEVV-01 — Define evaluation objectives, context, and measurements
The framework starts with organizational goals and the system's operational context, then constructs measurement concepts, test events, and tools that address those objectives.
control · Context
NIST-TEVV-02 — Run evaluations and examine results and limitations
The framework applies the selected tests and synthesizes their results into evidence about system performance, while interrogating the measurements and what the findings support.
control · Context
NIST-TEVV-03 — Evaluate AI systems in realistic operating settings
The draft discusses testing in settings that better reflect real use, including interactions with users and the operating environment, to complement model tests and benchmarks.
control · Context
NIST-TEVV-04 — Test for disclosure of confidential information
Appendix B includes confidentiality attacks that test whether an AI system reveals confidential information or internal functionality, including user information and system-prompt leakage.
control · Context
DE.AE-02 — Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
control · Context
DE.AE-03 — Adverse Event Analysis: Information is correlated from multiple sources
Adverse Event Analysis: Information is correlated from multiple sources
control · Context
DE.AE-04 — Adverse Event Analysis: The estimated impact and scope of adverse events are understood
Adverse Event Analysis: The estimated impact and scope of adverse events are understood
control · Context
DE.AE-06 — Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
control · Context
DE.AE-07 — Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
control · Context
DE.AE-08 — Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
control · Context
DE.CM-01 — Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
control · Context
DE.CM-02 — Continuous Monitoring: The physical environment is monitored to find potentially adverse events
Continuous Monitoring: The physical environment is monitored to find potentially adverse events
control · Context
DE.CM-03 — Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
control · Context
DE.CM-06 — Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
control · Context
GV.RM-03 — Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
control · Context
ID.RA-07 — Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
control · Context
PR.AA-01 — Identity Management, Authentication, and Access Control: Identities and credentials for authorized users, services, and hardware are managed by the organization
Identity Management, Authentication, and Access Control: Identities and credentials for authorized users, services, and hardware are managed by the organization
control · Context
PR.AA-02 — Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
control · Context
PR.AA-05 — Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
control · Context
PR.AT-01 — Awareness and Training: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
Awareness and Training: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
control · Context
PR.AT-02 — Awareness and Training: Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
Awareness and Training: Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
control · Context
PR.DS-11 — Data Security: Backups of data are created, protected, maintained, and tested
Data Security: Backups of data are created, protected, maintained, and tested
control · Context
PR.IR-01 — Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
control · Context
PR.IR-03 — Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
control · Context
PR.IR-04 — Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
control · Context
PR.PS-04 — Platform Security: Log records are generated and made available for continuous monitoring
Platform Security: Log records are generated and made available for continuous monitoring
control · Context
PR.PS-05 — Platform Security: Installation and execution of unauthorized software are prevented
Platform Security: Installation and execution of unauthorized software are prevented
control · Context
RC.CO-03 — Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
control · Context
RC.CO-04 — Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
control · Context
RC.RP-01 — Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
control · Context
RC.RP-02 — Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
control · Context
RC.RP-03 — Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
control · Context
RC.RP-04 — Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
control · Context
RC.RP-05 — Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
control · Context
RC.RP-06 — Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
control · Context
RS.AN-03 — Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
control · Context
RS.AN-06 — Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
control · Context
RS.AN-07 — Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
control · Context
RS.AN-08 — Incident Analysis: An incident's magnitude is estimated and validated
Incident Analysis: An incident's magnitude is estimated and validated
control · Context
RS.MA-01 — Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
control · Context
RS.MA-02 — Incident Management: Incident reports are triaged and validated
Incident Management: Incident reports are triaged and validated
control · Context
RS.MA-03 — Incident Management: Incidents are categorized and prioritized
Incident Management: Incidents are categorized and prioritized
control · Context
RS.MA-04 — Incident Management: Incidents are escalated or elevated as needed
Incident Management: Incidents are escalated or elevated as needed
control · Context
RS.MA-05 — Incident Management: The criteria for initiating incident recovery are applied
Incident Management: The criteria for initiating incident recovery are applied
control · Context
RS.MI-01 — Incident Mitigation: Incidents are contained
Incident Mitigation: Incidents are contained
control · Context
RS.MI-02 — Incident Mitigation: Incidents are eradicated
Incident Mitigation: Incidents are eradicated
control · Context
500.14 — Monitoring and training
Monitoring and training
control · Context
500.6 — Audit trail
Audit trail
control · Context
500.7 — Access privileges and management
Access privileges and management
control · Context
500.9 — Risk assessment
Risk assessment
control · Context
PCI-Req10 — Log and monitor all access to system components and cardholder data
Log and monitor all access to system components and cardholder data
control · Context
PCI-Req7 — Restrict access to system components and cardholder data by business need to know
Restrict access to system components and cardholder data by business need to know
control · Context
SOC1-1 — Logical access — controls provide reasonable assurance that logical access to applications, data, and infrastructure is restricted to authorized and appropriate users (authentication, authorization, provisioning/deprovisioning, periodic access review, privileged access).
Logical access — controls provide reasonable assurance that logical access to applications, data, and infrastructure is restricted to authorized and appropriate users (authentication, authorization, provisioning/deprovisioning, periodic access review, privileged access).
control · Context
SOC1-11 — System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
control · Context
SOC1-4 — Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
control · Context
SOC1-5 — Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
control · Context
SOC1-6 — Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
control · Context
SOC1-7 — Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
control · Context
SOC1-8 — Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
control · Context
SOC1-9 — Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
control · Context
A1.1 — The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
control · Context
A1.2 — The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
control · Context
A1.3 — The entity tests recovery plan procedures supporting system recovery to meet its objectives.
The entity tests recovery plan procedures supporting system recovery to meet its objectives.
control · Context
CC3.2 — The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
control · Context
CC6.2 — Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
control · Context
CC6.3 — The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.
The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.
control · Context
CC6.6 — The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
control · Context
CC7.2 — The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
control · Context
CC7.3 — The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
control · Context
CC7.4 — The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
control · Context
CC7.5 — The entity identifies, develops, and implements activities to recover from identified security incidents.
The entity identifies, develops, and implements activities to recover from identified security incidents.
control · Context
PI1.2 — The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
control · Context
ELC-RA — Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
control · Context
ITGC-AC — Access to programs and data — logical and physical access security: authentication, authorization, user provisioning/deprovisioning, periodic access recertification, privileged/administrative access, and segregation of duties enforced via access.
Access to programs and data — logical and physical access security: authentication, authorization, user provisioning/deprovisioning, periodic access recertification, privileged/administrative access, and segregation of duties enforced via access.
control · Context
ITGC-OPS — Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
control · Context
PLC-AUTH — Authorization and approval — transactions, journal entries, and changes are reviewed and approved by authorized personnel in accordance with delegation-of-authority policies before being recorded or executed.
Authorization and approval — transactions, journal entries, and changes are reviewed and approved by authorized personnel in accordance with delegation-of-authority policies before being recorded or executed.
control · Context
PLC-INPUT — Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
risk · Direct
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 · Direct
Model/data drift and inadequate post-deployment monitoring
Distribution shift between training and deployment data silently degrades accuracy, and without ongoing monitoring, model decay and emerging failure modes go undetected with no trigger to retrain or decommission. Uncontrolled updates alter behaviour and invalidate prior assessments.
risk · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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.
standard · Context
AIUC-1 (Jul 2026)
AIUC-1 — AI agent security, safety and reliability standard (requirement level)
standard · Context
CCPA/CPRA
CCPA/CPRA — California Consumer Privacy
standard · Context
COBIT 2019
COBIT 2019 Governance & Management Objectives
standard · Context
COSO ERM 2017
COSO ERM – Integrating with Strategy and Performance (2017)
standard · Context
COSO IC 2013
COSO Internal Control – Integrated Framework (2013)
standard · Context
EU DORA
EU DORA — Digital Operational Resilience Act
standard · Context
EU AI Act
EU AI Act — principal obligation areas (Chapters II, III, V and IX)
standard · Context
EU GDPR
EU GDPR — General Data Protection Regulation
standard · Context
HIPAA
HIPAA — Security, Privacy & Breach Notification
standard · Context
IIA 2024 Standards
IIA 2024 Global Internal Audit Standards
standard · Context
The Role of the Internal Audit Function in Enterprise Risk Management
The Role of the Internal Audit Function in Enterprise Risk Management
standard · Context
Three Lines Model: Assurance and Advice in Support of Effective Governance
Three Lines Model: Assurance and Advice in Support of Effective Governance
standard · Context
ISO/IEC 27001:2022
ISO/IEC 27001:2022 Annex A
standard · Context
ISO 31000:2018
ISO 31000:2018 Risk Management (principles/framework/process)
standard · Context
ISO/IEC 42001:2023 (AI)
ISO/IEC 42001:2023 Annex A (AI Management System)
standard · Context
EU NIS2
EU NIS2 Directive
standard · Context
NIST SP 800-53 Rev5
NIST SP 800-53 Rev 5 — Security and Privacy Controls
standard · Context
NIST Agent Identity (draft, Feb 2026)
NIST NCCoE: Software and AI Agent Identity and Authorization
standard · Context
NIST TEVV-Athlon (draft, Aug 2026)
NIST AI 200-2: TEVV-Athlon Framework for Evaluating AI Systems
standard · Context
NIST CSF 2.0
NIST Cybersecurity Framework 2.0
standard · Context
NYDFS Part 500
NYDFS Part 500 — NY Cybersecurity Regulation
standard · Context
PCI DSS v4.0.1
PCI DSS v4.0.1
standard · Context
SOC 1
SOC 1 (SSAE 18 / ISAE 3402) — service-org ICFR control objectives
standard · Context
SOC 2 (TSC)
AICPA SOC 2 Trust Services Criteria (2017, rev. 2022)
standard · Context
SOX / PCAOB (ICFR)
SOX 404 / PCAOB AS 2201 — ICFR control taxonomy
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-02 — Review user access rights periodically
All user and privileged access rights are reviewed at least annually, and more frequently for high-risk systems, by system or data owners who confirm each entitlement remains limited to business need. Unnecessary accounts and excess privileges identified in reviews are disabled or removed within a defined SLA. Completed reviews and remediation evidence are retained.
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-04 — Restrict privileged rights, utilities, and unauthorized software
Privileged access rights are individually authorized against a business justification, time-bound or periodically recertified, and issued on separate accounts distinct from daily-use identities. Use of utility programs capable of overriding system or application controls is restricted to authorized administrators and logged. Application allowlisting or equivalent controls prevent installation and execution of unauthorized software on managed systems.
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-17 — Execute, monitor, and recover production processing
Production batch jobs and scheduled processing are defined, authorized, and monitored, with failures and exceptions logged, tracked, and resolved in a timely manner. Data is backed up on a defined schedule with protected, retained copies, and restoration is periodically tested to confirm recoverability within objectives.
unified · Direct
UC-ACCESS-18 — Log and monitor system activity, capacity, and incidents
Systems generate log records that are protected and made available for continuous monitoring. Performance, capacity, and security events are monitored against thresholds, with alerts triaged and incidents identified and resolved through a tracked process. Resource use is projected and tuned to meet current and future capacity requirements.
unified · Context
UC-ACCESS-20 — Ensure complete, accurate, and authorized data processing
Transactions and data entering the system are validated for completeness, accuracy, and authorization through edit checks, batch totals, and exception queues. Interfaces and transmissions between systems are controlled with reconciliation, error handling, and timeliness checks, and processing applies complete and accurate logic in the proper period. Outputs and reports are validated and distributed only to authorized recipients.
unified · Context
UC-AI-07 — Verify, validate, and control AI deployment and changes
Verify and validate each AI system against its requirements and responsible-AI objectives, documenting test plans, acceptance criteria, and results before release approval. Gate deployment on a documented deployment plan and sign-off confirming requirements are met. Route updates, retraining, and other changes through the same assessment and approval process, including impact reassessment where relevant, and retain verification records and deployment and change approvals.
unified · Context
UC-AI-08 — Log and monitor AI system behavior in operation
Ensure AI systems automatically record event logs that enable traceability of operation over the system's lifetime, including events relevant to identifying risk situations and substantial modification. Retain logs for at least the mandated regulatory minimum, or longer where required. Monitor deployed systems against defined performance and behavior metrics with alerting and escalation for anomalies and drift, and retain logs and monitoring reviews as evidence.
unified · Context
UC-AI-21 — Commission independent third-party AI evaluations on a quarterly cadence
Engage an independent evaluator at least quarterly to test each in-scope AI system against its defined risk categories: adversarial robustness and jailbreak resistance, harmful and out-of-scope outputs, agent-specific high-risk outputs, hallucination rates, and unsafe or unauthorized tool calls. Fix the test scope and pass thresholds in advance, track every finding to remediation and retest, and retain evaluator reports, methodologies, and remediation evidence.
unified · Context
UC-ASSET-10 — Assess and track changes and exceptions for risk impact
Manage changes and exceptions to the environment and to security requirements through a process that assesses risk impact before approval. Record each change or exception with its assessment, approver, owner, and expiry or review date, and track open items to closure.
unified · Context
UC-ASSET-12 — Operate scheduled processing, backup, and availability monitoring
Schedule and monitor batch jobs and system processing, investigating and resolving failures through documented incident and problem management. Perform and verify data backups and periodically test recovery capability. Monitor system processing and availability against defined service expectations, with documented follow-up on deviations.
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-06 — Resolve operational incidents and eliminate root causes
Log, classify, and prioritize operational and security incidents and service requests, respond within defined service levels, and escalate by severity until service is restored. Classify and report major ICT incidents to regulators, customers, and affected parties within required timeframes. Perform root-cause analysis of significant and recurring incidents, and track underlying problems through to permanent resolution.
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-08 — Declare recovery complete and set post-incident norms
Define criteria for ending incident recovery and formally declare recovery complete only when those criteria are met. Complete all incident and recovery documentation, and establish post-incident operational norms that account for critical mission functions and residual cybersecurity risk.
unified · Context
UC-BCDR-09 — Communicate recovery status to stakeholders
Communicate recovery activities, progress, and estimated restoration timelines to designated internal and external stakeholders through pre-defined channels and cadences. Release public updates about incident recovery only through approved spokespersons, methods, and messaging.
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 · Direct
UC-BCDR-13 — Operate continuous security protection services
Operate ongoing protection services, including malware defense, network and endpoint security, and security monitoring, so that attacks and disruptions do not compromise service availability or data. Review and tune these services regularly to keep security risk within accepted levels.
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-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-FIN-06 — Validate completeness and accuracy of system inputs
Implement input controls over data entered into financial systems, including edit and validation checks, required-field and format controls, completeness checks, and rejection or suspense handling of invalid entries, so that inputs are complete, accurate, and valid. Define these controls in documented policies and procedures over system inputs and retest their configuration on change. Evidence includes configuration baselines, validation rules, and rejected-input handling records.
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-04 — Triage, categorize, and escalate reported security events
Triage every reported security event: validate that it is genuine, assess it against the agreed classification scheme, and decide whether to declare it an incident. Categorize and prioritize declared incidents by type, severity, and business impact, and escalate or elevate them to defined roles and management tiers according to documented thresholds and timeframes. Record triage decisions and their rationale in the incident system of record.
unified · Context
UC-IR-05 — Assess and validate incident scope, impact, and magnitude
For each declared or suspected incident, estimate the scope of affected systems, data, and business processes and the resulting impact, and validate those estimates as investigation proceeds. Document magnitude assessments — records affected, service disruption, and financial exposure — and update them at defined points so response priority, escalation, and notification decisions rest on current, validated figures.
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-09 — Recover from incidents using defined initiation criteria
Define objective criteria for initiating incident recovery — such as confirmed eradication, completed forensic preservation, and management authorization — and apply them before restoration begins. Identify, develop, and execute recovery activities that restore affected systems, data, and services to a known-good state, verifying integrity before return to production and confirming with business owners that normal operations have resumed.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-LOG-06 — Evaluate events and declare incidents against defined criteria
Define written criteria for declaring a security incident, including thresholds that identify a reportable personal-data breach. Evaluate analyzed events against those criteria, declare incidents and initiate the response process when criteria are met, and record the assessment and rationale for every evaluated event. For reportable personal-data breaches, notify the competent regulator within the mandated statutory window with the prescribed content, and document all breaches, their effects, and remediation regardless of whether notification was required.
unified · Direct
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 · Direct
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 · Direct
UC-LOG-10 — Monitor the physical environment for adverse events
Monitor the physical environment of facilities hosting systems and data — using mechanisms such as camera surveillance, badge and entry logs, and environmental sensors — to detect potentially adverse physical events. Review physical-access records and environmental alerts on a defined cadence and feed anomalies into security-event analysis.
unified · Direct
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-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-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-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-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-RISK-02 — Integrate risk management into enterprise processes and projects
Risk management is integrated into organizational structures, decision-making, and business activities rather than operated as a standalone silo. Cybersecurity and information security risk activities are incorporated into enterprise risk management processes, and information security risk is addressed within project management for all projects from initiation through delivery. ERM artifacts referencing cyber risk and project gate documentation with security risk sections evidence operation.
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-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-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.
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
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
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
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
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
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
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
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
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
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
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
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
Physical Environment Monitoring Review
Standing operator workflow for the monthly physical-environment monitoring review across facilities hosting systems and data — badge and entry logs, camera surveillance coverage and footage, and environmental sensor alerts. Each cycle runs as a recurring workflow instance attached to the existing UC-LOG-10 Control item (control_type=detective, control_category=physical, frequency=monthly, framework=nist-csf-2, domains include physical_environmental_security and logging_monitoring_detection) — it enriches that Control's execution history and never creates a duplicate control. In scope: physical-access, surveillance, and environmental monitoring of the in-scope facilities and the systems and data they host. Out of scope: logical-access review and the downstream analysis and remediation of confirmed events, which are handed off to the security-event analysis workflow. Runs on a routine monthly cadence (or out-of-cycle after a triggering incident) with no upstream workflow feeding it — it originates from the anchor Control, its prior-cycle instance, and the prior cycle's still-open Issue items. Consolidates findings into a de-duplicated physical-event register, packages every confirmed adverse physical event as a security-event case handed off to the security-event analysis workflow, and tracks monitoring coverage gaps to closure as owned corrective-action Issues. Implements NIST CSF 2.0 continuous detection monitoring (control UC-LOG-10).
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
AI Operations Monitoring & Incident Response
Each monthly instance runs against the existing Control item for AI operations monitoring and incident response (framework eu-ai-act + iso-42001; domains ai_governance / logging_monitoring_detection / incident_management_response; frequency monthly; control_owner AI Operations Manager) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate. The decision-aware cycle covers event-logging and retention verification, alert resolution, human-oversight confirmation, AI-use screening against legal prohibitions, and AI concern-and-incident triage through required communications and regulator reporting, consolidating all five streams into a named cycle report and cycle dashboard while every residual gap is booked as an Issue (source: management_identified) linked to the anchor Control. In scope: every deployed production, limited-risk, and high-risk AI system under the EU AI Act, its event-log sources and monitoring dashboards, the human-oversight roster, the AI use inventory, and the AI concern-reporting channels. Out of scope: pre-deployment model development and conformity assessment, and third-party/vendor AI due diligence, which are governed by their own workflows. This cycle consumes no upstream workflow handoff; it hands off only to the next monthly run of itself, seeding it with the open carry-forward Issues (corrective actions, in-flight blocks, incident follow-ups) that the cycle-metrics-and-report step links to the anchor Control so next month can query them as its prior-cycle input.
workflow · Context
Quarterly Third-Party AI Evaluation Cycle
Each quarterly instance runs against the existing Control item for independent third-party AI evaluation (framework aiuc-1 + iso-42001 + eu-ai-act; domains ai_governance; frequency quarterly; control_owner AI Product Lead) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate Control; the one record it does create is a per-quarter Audit item (audit_type: it_audit) for the evaluator engagement. The decision-aware cycle confirms the quarter's in-scope systems and risk taxonomy, engages an independent evaluator with the test plan, categories, and pass thresholds fixed in advance, provisions contained test access, triages every finding by category and severity against the tested control, routes failed thresholds through remediation and evaluator retest, gates acceptance of the evaluator report, publishes the accepted evidence (trust-portal summary, customer-facing attestation, evidence register), and tunes guardrails from the findings. In scope: every in-scope AI system and agent under the AIUC-1 program and its six mandatory third-party test categories (B001 adversarial robustness, C010 harmful outputs, C011 out-of-scope outputs, C012 agent-specific risk, D002 hallucinations, D004 tool calls). Out of scope: internal red-teaming, pre-release model evaluation, and vendor AI due diligence, which run in their own workflows. It hands off only to the next quarterly run of itself, seeding it with the open carry-forward finding Issues that the publish-evidence-and-tune-guardrails step links to the anchor Control.
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
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
Periodic User Access Review
Runs on the existing system item. Run a periodic entitlement recertification for a system, evidence reviewer decisions, and confirm that required revocations were executed. 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
Job Scheduling & Batch Monitoring
Runs on the existing system item. Review scheduled job execution for a system over a period, evidencing failure detection, escalation, and resolution. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Data Conversion & Migration
Runs on the existing system item. Convert data into a target system with evidenced completeness and accuracy reconciliation between source and target. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
End-User Computing Inventory & Validation
Runs on the existing system item. Inventory the spreadsheets and end-user tools feeding reporting for a system, and test their access, change, and integrity controls. 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
Incident & Problem Management
Runs on the existing system item. Record an incident on a system, evidence containment against response targets, and determine root cause with preventive action. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Privileged Access Review
Runs on the existing system item. Review privileged, service, and emergency accounts on a system for continued business justification, supporting activity, and compensating monitoring. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
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 Processing Integrity Assessment
Design-readiness review of the SOC 2 processing integrity series: processing definitions and specifications, input controls, processing controls, output delivery, and storage integrity (PI1.1–PI1.5). 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
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
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
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
AI Governance & Risk/Impact Assessment
Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.
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
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
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
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
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
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
Enterprise GRC Platform Integration Bridge
Runs on a Process item created at kickoff (process_type = it_general_control, process_owner = the integration owner, frequency = the sync cadence) that represents the bridge as an operated, auditable IT process — the workflow instance attaches to and enriches that Process item, never a duplicate. Bridges an external enterprise GRC platform (e.g., RSA Archer, ServiceNow GRC, Workday, AuditBoard) with AssureSwarm: define field and ID mappings, run the initial migration or provisioning (which creates Risk / Control / Issue / Audit / Policy items and Control-hosted testing workflows for imported control-test records), operate a monitored bidirectional scheduled sync, resolve conflicts, and confirm system-of-record agreement. This workflow originates the integration project — it consumes no upstream handoff. In scope: mapping design, initial load, ongoing sync operation and health monitoring, conflict resolution, and system-of-record sign-off. Out of scope: standing up the external GRC platform itself, and the downstream assurance analysis. The named deliverable is a version-stamped final bridge package (evidence index, executive summary, authoritative per-field system-of-record coverage table, open-items list), handed to the Combined Assurance Mapping workflow, which consumes it rather than re-deriving the record inventory.
workflow · Context
AI System Development, Data & Deployment Gate
Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).
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
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
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
Financial Systems Transaction Integrity Monitoring
Each cycle runs as a workflow instance attached to the EXISTING financial-reporting Process item (process_type=financial_reporting) that represents financial-systems transaction processing; the four unified controls it operates (UC-FIN-06 through UC-FIN-09) are EXISTING Control items linked to that Process — enrich them, never recreate them. A decision-aware workflow covering input-control queue clearance and configuration revalidation, automated-processing exception disposition and configuration-change approval, interface reconciliation and failure resolution, and system-generated report validation and baselining. It consumes the prior cycle's carry-forward open items (Issue items created when that cycle's evidence package was certified and closed, linked to their Control) as this cycle's scope. In scope each cycle: every in-scope input control, automated processing control, interface, and relied-upon standard report for the cycle window, with change-flagged items retested and prior-cycle carryovers carried forward. The named deliverable is the control-indexed cycle evidence package with the owner's signed certification statement. There is no downstream workflow — the workflow is terminal and self-seeding: the open items this cycle discloses become carry-forward Issue items that seed the next run of this same cycle on the same Process.
workflow · Context
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
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 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.