Financial Reporting Controls (SOX)
331 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
B007 — Enforce user access privileges to AI systems
Enforce user access privileges to AI systems
control · Context
C001 — Define AI risk taxonomy
Define AI risk taxonomy
control · Context
APO01 — Managed I&T Management Framework
Managed I&T Management Framework
control · Context
APO06 — Managed Budget and Costs
Managed Budget and Costs
control · Context
APO14 — Managed Data
Managed Data
control · Context
DSS06 — Managed Business Process Controls
Managed Business Process Controls
control · Context
EDM01 — Ensured Governance Framework Setting and Maintenance
Ensured Governance Framework Setting and Maintenance
control · Context
EDM04 — Ensured Resource Optimization
Ensured Resource Optimization
control · Context
MEA02 — Managed System of Internal Control
Managed System of Internal Control
control · Context
E1 — Exercises Board Risk Oversight
Exercises Board Risk Oversight
control · Context
E14 — Develops Portfolio View
Develops Portfolio View
control · Context
E3 — Defines Desired Culture
Defines Desired Culture
control · Context
E4 — Demonstrates Commitment to Core Values
Demonstrates Commitment to Core Values
control · Context
P1 — The organization demonstrates a commitment to integrity and ethical values.
The organization demonstrates a commitment to integrity and ethical values.
control · Context
P10 — The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
control · Context
P11 — The organization selects and develops general control activities over technology to support the achievement of objectives.
The organization selects and develops general control activities over technology to support the achievement of objectives.
control · Context
P16 — The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
control · Context
P2 — The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
control · Context
P5 — The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
control · Context
P8 — The organization considers the potential for fraud in assessing risks to the achievement of objectives.
The organization considers the potential for fraud in assessing risks to the achievement of objectives.
control · Context
AIA-Art27 — Fundamental rights impact assessment for high-risk AI systems (deployers)
Fundamental rights impact assessment for high-risk AI systems (deployers)
control · Context
AIA-Art6-7 — Risk-based classification of high-risk AI systems
Risk-based classification of high-risk AI systems
control · Context
GDPR-Art32 — Security of processing
Security of processing
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
Principle 1 — Demonstrate Integrity
Demonstrate Integrity
control · Context
Principle 10 — Manage Resources
Manage Resources
control · Context
Principle 14 — Conduct Engagement Work
Conduct Engagement Work
control · Context
Principle 15 — Communicate Engagement Results and Monitor Action Plans
Communicate Engagement Results and Monitor Action Plans
control · Context
Principle 3 — Demonstrate Competency
Demonstrate Competency
control · Context
Principle 4 — Exercise Due Professional Care
Exercise Due Professional Care
control · Context
Principle 6 — Authorized by the Board
Authorized by the Board
control · Context
Principle 9 — Plan Strategically
Plan Strategically
control · Context
Std 1.1 — Honesty and Professional Courage
Honesty and Professional Courage
control · Context
Std 1.2 — Organization's Ethical Expectations
Organization's Ethical Expectations
control · Context
Std 1.3 — Legal and Ethical Behavior
Legal and Ethical Behavior
control · Context
Std 10.1 — Financial Resource Management
Financial Resource Management
control · Context
Std 10.2 — Human Resources Management
Human Resources Management
control · Context
Std 10.3 — Technological Resources
Technological Resources
control · Context
Std 11.3 — Communicating Results
Communicating Results
control · Context
Std 11.4 — Errors and Omissions
Errors and Omissions
control · Context
Std 14.1 — Gathering Information for Analyses and Evaluation
Gathering Information for Analyses and Evaluation
control · Context
Std 14.2 — Analyses and Potential Engagement Findings
Analyses and Potential Engagement Findings
control · Context
Std 14.3 — Evaluation of Findings
Evaluation of Findings
control · Context
Std 14.4 — Recommendations and Action Plans
Recommendations and Action Plans
control · Context
Std 14.5 — Engagement Conclusions
Engagement Conclusions
control · Context
Std 15.1 — Final Engagement Communication
Final Engagement Communication
control · Context
Std 3.1 — Competency
Competency
control · Context
Std 3.2 — Continuing Professional Development
Continuing Professional Development
control · Context
Std 4.1 — Conformance with the Global Internal Audit Standards
Conformance with the Global Internal Audit Standards
control · Context
Std 4.2 — Due Professional Care
Due Professional Care
control · Context
Std 4.3 — Professional Skepticism
Professional Skepticism
control · Context
Std 6.1 — Internal Audit Mandate
Internal Audit Mandate
control · Context
Std 6.2 — Internal Audit Charter
Internal Audit Charter
control · Context
Std 6.3 — Board and Senior Management Support
Board and Senior Management Support
control · Context
Std 9.1 — Understanding Governance, Risk Management, and Control Processes
Understanding Governance, Risk Management, and Control Processes
control · Context
Std 9.2 — Internal Audit Strategy
Internal Audit Strategy
control · Context
Std 9.4 — Internal Audit Plan
Internal Audit Plan
control · Context
IIA-POS-ERM-04 — Assurance and Advisory Portfolio Calibration
The assurance/advisory mix is calibrated to ERM maturity and resources, strategic and risk context, other-provider strength, and board direction.
control · Context
A.5.15 — Access control
Access control
control · Context
A.5.18 — Access rights
Access rights
control · Context
A.5.3 — Segregation of duties
Segregation of duties
control · Context
A.5.33 — Protection of records
Protection of records
control · Context
A.5.4 — Management responsibilities
Management responsibilities
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.3 — Information access restriction
Information access restriction
control · Context
A.8.4 — Access to source code
Access to source code
control · Context
31000-PR8 — Recording and reporting
Recording and reporting
control · Context
A.5.2 — AI system impact assessment process
AI system impact assessment process
control · Context
A.5.3 — Documentation of AI system impact assessments
Documentation of AI system impact assessments
control · Context
A.5.4 — Assessing AI system impact on individuals or groups of individuals
Assessing AI system impact on individuals or groups of individuals
control · Context
A.5.5 — Assessing societal impacts of AI systems
Assessing societal impacts of AI systems
control · Context
NIS2-Art20 — Governance and management body accountability / training
Governance and management body accountability / training
control · Context
NIS2-Art21i — Human resources security, access control policies and asset management
Human resources security, access control policies and asset management
control · Context
AC-1 — Policy and Procedures
Policy and Procedures
control · Context
AC-16 — Security and Privacy Attributes
Security and Privacy Attributes
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-5 — Separation of Duties
Separation of Duties
control · Context
AC-6 — Least Privilege
Least Privilege
control · Context
AU-10 — Non-repudiation
Non-repudiation
control · Context
AU-14 — Session Audit
Session Audit
control · Context
CA-2 — Control Assessments
Control Assessments
control · Context
IA-1 — Policy and Procedures
Policy and Procedures
control · Context
PL-10 — Baseline Selection
Baseline Selection
control · Context
PL-11 — Baseline Tailoring
Baseline Tailoring
control · Context
PL-2 — System Security and Privacy Plans
System Security and Privacy Plans
control · Context
PL-4 — Rules of Behavior
Rules of Behavior
control · Context
PL-7 — Concept of Operations
Concept of Operations
control · Context
PL-9 — Central Management
Central Management
control · Context
PM-12 — Insider Threat Program
Insider Threat Program
control · Context
PM-14 — Testing, Training, and Monitoring
Testing, Training, and Monitoring
control · Context
PM-16 — Threat Awareness Program
Threat Awareness Program
control · Context
PM-2 — Information Security Program Leadership Role
Information Security Program Leadership Role
control · Context
PM-23 — Data Governance Body
Data Governance Body
control · Context
PM-24 — Data Integrity Board
Data Integrity Board
control · Context
PM-29 — Risk Management Program Leadership Roles
Risk Management Program Leadership Roles
control · Context
PM-3 — Information Security and Privacy Resources
Information Security and Privacy Resources
control · Context
PM-32 — Purposing
Purposing
control · Context
PS-1 — Policy and Procedures
Policy and Procedures
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
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
GV.OV-01 — Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
control · Context
GV.RR-01 — Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
control · Context
GV.RR-03 — Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
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-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.PS-05 — Platform Security: Installation and execution of unauthorized software are prevented
Platform Security: Installation and execution of unauthorized software are prevented
control · Context
500.4 — Chief Information Security Officer (CISO)
Chief Information Security Officer (CISO)
control · Context
500.7 — Access privileges and management
Access privileges and management
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-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
CC1.1 — The entity demonstrates a commitment to integrity and ethical values.
The entity demonstrates a commitment to integrity and ethical values.
control · Context
CC1.2 — The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
control · Context
CC1.5 — The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
control · Context
CC2.1 — The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
control · Context
CC3.3 — The entity considers the potential for fraud in assessing risks to the achievement of objectives.
The entity considers the potential for fraud in assessing risks to the achievement of objectives.
control · Context
CC5.1 — The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
control · Context
CC5.2 — The entity also selects and develops general control activities over technology to support the achievement of objectives.
The entity also selects and develops general control activities over technology to support the achievement of objectives.
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
PI1.1 — The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
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
PI1.3 — The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
control · Context
PI1.4 — The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
control · Context
PI1.5 — The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
control · Context
ELC-CA — Control Activities (entity-level) — policies and procedures, period-end financial reporting process oversight, and entity-wide control activities including technology general controls policies.
Control Activities (entity-level) — policies and procedures, period-end financial reporting process oversight, and entity-wide control activities including technology general controls policies.
control · Context
ELC-CE — Control Environment — tone at the top, integrity and ethical values, code of conduct, board/audit committee oversight, organizational structure, assignment of authority and responsibility, commitment to competence, HR policies.
Control Environment — tone at the top, integrity and ethical values, code of conduct, board/audit committee oversight, organizational structure, assignment of authority and responsibility, commitment to competence, HR policies.
control · Context
ELC-MGMT-OVR — Anti-fraud and management override controls — controls addressing the risk of management override of controls, including journal-entry review and review of significant estimates.
Anti-fraud and management override controls — controls addressing the risk of management override of controls, including journal-entry review and review of significant estimates.
control · Context
ELC-MON — Monitoring Activities — ongoing and separate evaluations (internal audit, management self-assessment, disclosure committee), and evaluation/communication of control deficiencies.
Monitoring Activities — ongoing and separate evaluations (internal audit, management self-assessment, disclosure committee), and evaluation/communication of control deficiencies.
control · Context
ELC-PERFR — Period-End Financial Reporting Process — controls over the close process, consolidation, journal entries, estimates, and preparation of financial statements and disclosures.
Period-End Financial Reporting Process — controls over the close process, consolidation, journal entries, estimates, and preparation of financial statements and disclosures.
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-CALC — Automated processing / configurable controls — system-enforced calculations, three-way matches, tolerance checks, and configurable application controls operating as designed.
Automated processing / configurable controls — system-enforced calculations, three-way matches, tolerance checks, and configurable application controls operating as designed.
control · Context
PLC-EXCEPTION — Exception and edit-report controls — review and timely resolution of system-generated exception, error, and edit reports.
Exception and edit-report controls — review and timely resolution of system-generated exception, error, and edit reports.
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.
control · Context
PLC-INTF — Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
control · Context
PLC-IPE — Information Produced by the Entity (IPE) / completeness and accuracy — controls over the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting.
Information Produced by the Entity (IPE) / completeness and accuracy — controls over the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting.
control · Context
PLC-MRC — Management review controls — reviews of financial information, account analyses, budget-to-actual variances, estimates, and reconciliations performed at an appropriate level of precision with documented investigation and resolution of items.
Management review controls — reviews of financial information, account analyses, budget-to-actual variances, estimates, and reconciliations performed at an appropriate level of precision with documented investigation and resolution of items.
control · Context
PLC-PHYS — Physical safeguards / custody controls — controls over physical custody of assets, inventory counts, and safeguarding of negotiable instruments and records.
Physical safeguards / custody controls — controls over physical custody of assets, inventory counts, and safeguarding of negotiable instruments and records.
control · Context
PLC-RECON — Reconciliations — account and subledger-to-general-ledger reconciliations performed completely and accurately, with timely review, approval, and resolution of reconciling items.
Reconciliations — account and subledger-to-general-ledger reconciliations performed completely and accurately, with timely review, approval, and resolution of reconciling items.
control · Context
PLC-SOD — Segregation of duties — incompatible duties (authorization, recording, custody, reconciliation) are divided among different people to reduce the risk of error or fraud.
Segregation of duties — incompatible duties (authorization, recording, custody, reconciliation) are divided among different people to reduce the risk of error or fraud.
risk · Direct
Unlawful denial of essential services by AI
Because AI evaluating eligibility for public benefits, creditworthiness, or insurance risk and pricing (Annex III(5)) operates without fairness, explainability, human oversight, or the required conformity controls, it can wrongly deny or misprice essential services, resulting in unlawful exclusion and consumer harm.
risk · Direct
Measurement and calculation errors (accuracy)
Errors in revenue recognition amounts, cost of goods sold, depreciation/amortization, payroll calculations, fair-value measurement, journal-entry posting, tax provision, and foreign-currency translation misstating the financial statements.
risk · Direct
Understatement of liabilities/expenses (completeness)
Unrecorded payables (cut-off failure), accrued expenses, unrecorded revenue for delivered goods, off-balance-sheet obligations, uncaptured inventory write-downs, and understated payroll/tax liabilities — understating obligations and overstating income.
risk · Direct
Period cut-off errors
Revenue, vendor invoices, payroll, capital expenditure, treasury transactions, or tax provisions recorded in the wrong period — deliberately shifted to meet targets or erroneously mis-timed — distorting period results.
risk · Direct
Data-quality and IPE integrity failures in reporting
Poor data lineage, inconsistent master-data definitions, or uncontrolled data transformation (weak IPE completeness/accuracy) cause management decisions and regulatory reports to rest on inaccurate or incomplete data.
risk · Direct
Overstatement of assets/revenue (existence & occurrence)
Revenue, receivables, inventory, capitalized assets, prepaid expenses, treasury investments, or tax assets recorded without underlying existence or occurrence — inflating the balance sheet and income statement.
risk · Direct
Financial-statement fraud and management override
Intentional misstatement through fictitious revenue, phantom inventory/assets, ghost-employee payroll, or management override of controls — inflating results and deceiving investors and regulators.
risk · Direct
Ineffective ICFR / undisclosed material weakness
Because internal control over financial reporting is not maintained effectively - material weaknesses undetected or undisclosed and certifications signed despite known deficiencies - financial statements may be materially misstated and filings delayed or restated, resulting in SEC enforcement, delisting, securities-fraud liability, and loss of investor confidence.
risk · 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
Presentation and disclosure deficiencies
Debt misclassified as long-term, gross/net revenue errors, operating/non-operating misclassification, faulty segment reporting, undisclosed related-party transactions, unstated accounting-policy changes, going-concern and contingent-liability disclosure failures.
risk · Direct
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Direct
Rights, obligations and related-party misstatement
Pledged/encumbered assets recorded as unencumbered, lease classification errors, liabilities not the entity’s recorded (or vice versa), consignment/in-transit inventory mis-recorded, and non-arm’s-length related-party transactions without economic substance.
risk · Direct
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
risk · Direct
Tax provision, deferred-tax and uncertain-position misstatement
Errors in effective-tax-rate computation, deferred-tax rollforward, valuation-allowance realizability, uncertain-tax-position accrual (ASC 740/IAS 12), and discrete-item cut-off across interim periods.
risk · Direct
Valuation and impairment misstatement
Goodwill/long-lived-asset impairment not recognized, understated allowances for doubtful accounts, omitted inventory NRV write-downs, misstated pension/OPEB and contingent-liability reserves, and unassessed deferred-tax realizability — carrying assets above recoverable amounts.
risk · Direct
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Direct
Unauthorized activity — rogue trading, position mismarking, concealment
Losses from transactions not reported or of an unauthorized type, deliberate mismarking of positions, fictitious trade bookings to conceal losses, and circumvention of position/risk limits without disclosure (e.g. rogue trader).
risk · Direct
Weak internal control environment enabling fraud and error
Because the internal control environment is weak - segregation of duties absent, authorization frameworks inadequate, and tone at the top poor - fraudulent and erroneous transactions can be initiated and concealed, resulting in material misstatement and financial, regulatory, and reputational loss.
risk · Direct
Transaction-processing and execution errors
Data-entry (fat-finger) errors, incorrect settlement instructions, collateral-management errors, reconciliation failures, and mis-application of corporate actions cause failed settlement, penalties, and undetected position discrepancies.
risk · Direct
Failed or inaccurate mandatory regulatory reporting
Late or inaccurate regulatory transaction reporting, missed regulatory-return deadlines, inaccurate risk reporting to management, and errors in suspicious-activity reporting — breaching disclosure obligations to regulators and stakeholders.
risk · Direct
Securities-law and SEC-reporting non-compliance
Public-company reporting failures: late or restated SEC filings, disclosure-control deficiencies, and securities-fraud exposure distinct from the underlying ICFR weakness — triggering enforcement and delisting risk.
risk · Direct
Failed M&A, integration or divestiture
Acquisitions fail to achieve synergies due to cultural misalignment, IT-integration failure, or customer attrition; overpayment and hidden liabilities materialise as goodwill impairment; divestitures disrupt shared-service dependencies.
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-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-15 — Design control activities over technology access
Management selects and develops control activities, including general controls over technology, that mitigate identified access-related risks to acceptable levels, documented in a control matrix mapping risks to controls. Control designs cover the technology infrastructure, security management, and acquisition and development processes relevant to access, and are updated as risks and systems change.
unified · Direct
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-04 — Assess impacts and classify AI systems before deployment
Operate a documented AI impact assessment process performed before deployment and repeated on significant change, assessing consequences for individuals, groups of individuals, and society, including fairness, safety, and fundamental-rights effects. Classify each system against applicable regulatory risk categories, including any high-risk designation, and record the classification rationale. Retain assessment reports, approvals, and reassessment triggers as 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-AUDIT-02 — Establish a board-approved internal audit mandate and charter
The board establishes and approves the internal audit mandate - the function's authority, role, and responsibilities - and documents it in an internal audit charter that is reviewed and reapproved periodically. The charter grants unrestricted access to the records, personnel, and physical property relevant to engagements, and the board and senior management visibly champion and support the mandate. The approved charter and review records are retained.
unified · Context
UC-AUDIT-04 — Uphold integrity and ethical conduct in internal auditing
Internal auditors demonstrate integrity in their work and professional relationships: they act honestly, exhibit professional courage by communicating truthfully even when uncomfortable, comply with applicable laws and the organization's ethical expectations, and encourage ethical behavior across the organization. Ethics expectations are acknowledged by audit staff annually and deviations are addressed and documented.
unified · Context
UC-AUDIT-06 — Ensure auditor competency and continuing development
The internal audit function collectively possesses, and individual auditors apply, the knowledge, skills, and abilities required for their responsibilities, engaging qualified assistance where gaps exist. Auditors maintain and enhance their competency through continuing professional development, which is planned, tracked, and reviewed at least annually. Training records and competency assessments evidence operation.
unified · Context
UC-AUDIT-07 — Exercise due professional care and professional skepticism
Internal auditors exercise due professional care by conforming with applicable professional internal auditing standards and by assessing the nature, circumstances, and requirements of each engagement, including the interests of stakeholders and the relative complexity and significance of the work. Auditors apply professional skepticism, critically assessing the reliability and sufficiency of information before relying on it. Conformance is confirmed through supervisory and quality reviews.
unified · Context
UC-AUDIT-09 — Develop a risk-based internal audit strategy and plan
The chief audit executive develops an internal audit strategy aligned with organizational objectives and stakeholder expectations, grounded in a documented understanding of the organization's governance, risk management, and control processes. The strategy includes a documented assurance, advisory, and administrative capacity mix calibrated against ERM maturity and resourcing; strategic change and the current risk environment; the strength and reliability of other assurance providers; and board direction and stakeholder expectations. A risk-based internal audit plan covering the audit universe is created at least annually, approved by the board, and adjusted as the risk landscape changes. The capacity mix is reconsidered whenever the plan is refreshed, and material changes are communicated to senior management and the board with their coverage impact. The strategy, plan, capacity mix, board approvals, refresh decisions, and communications are retained.
unified · Context
UC-AUDIT-10 — Manage internal audit financial, human, and technology resources
The chief audit executive manages the function's resources to deliver the approved audit plan: a sufficient budget, recruitment, development, and deployment of qualified personnel, and technology that supports the audit process. Resource sufficiency is reassessed against the plan on a defined cadence, and the impact of any constraints on audit coverage is communicated to senior management and the board.
unified · Context
UC-AUDIT-13 — Gather and analyze evidence to develop engagement findings
Auditors gather information that is relevant, reliable, and sufficient to support analyses and evaluations, applying appropriate analytical methods and tools. Deviations between the established criteria and the observed condition are analyzed and assessed for significance and developed into potential findings documenting condition, criteria, cause, and effect. Evidence and analyses are captured in workpapers.
unified · Context
UC-AUDIT-14 — Evaluate findings and develop recommendations and action plans
Engagement findings are evaluated individually and collectively to formulate engagement conclusions relative to the engagement objectives, considering the significance of the findings. Recommendations and/or management action plans addressing root causes are developed, collaboratively where appropriate, and are supported by documented evidence. Conclusions and recommendations are reviewed before communication.
unified · Context
UC-AUDIT-16 — Communicate final engagement results to stakeholders
A final engagement communication is issued to appropriate parties for every engagement, presenting the objectives, scope, conclusions, findings, and recommendations or management action plans. Communications meet the quality expectations of being accurate, objective, clear, concise, constructive, complete, and timely. If a final communication contains a significant error or omission, corrected information is communicated to all recipients of the original.
unified · Context
UC-AUDIT-21 — Assess control effectiveness through testing and monitoring
Management operates a monitoring program over the system of internal control that combines ongoing evaluations with separate assessments, including management self-assessments and internal audit evaluations. Controls are assessed for design and operating effectiveness on a defined frequency by assessors with a level of independence appropriate to the assessment, under documented assessment plans, and plans for security testing, training exercises, and monitoring are developed, maintained, and executed. Identified deficiencies are evaluated and communicated to those responsible for corrective action, including senior management and the board as appropriate.
unified · Context
UC-AUDIT-25 — Maintain quality records and information for internal control
The organization obtains or generates and uses relevant, quality information to support the functioning of internal control, with defined expectations for accuracy, completeness, and timeliness. Records are protected against loss, destruction, falsification, and unauthorized access or release, and are retained and disposed of in accordance with retention schedules aligned to legal, regulatory, contractual, and business requirements.
unified · Direct
UC-BCDR-14 — Embed control activities in business processes
Define and operate control activities embedded within key business processes - input, processing, and output controls, segregation of duties and levels of authority, error and exception handling, and traceability of transactions - so that information processed remains complete, accurate, and valid.
unified · Direct
UC-FIN-01 — Deploy financial control activities through policies
Deploy control activities over financial reporting through formally approved policies and procedures that state what is expected and how it is performed, including entity-wide policies for technology general controls and oversight of the period-end financial reporting process. Assign owners, communicate the policies to responsible personnel, and review and reapprove them periodically. Evidence includes the approved policy set, periodic review sign-offs, and communication records.
unified · Direct
UC-FIN-02 — Review financial results and the period-end close
Execute the period-end close under a documented close calendar and checklist covering consolidation, journal entries, significant estimates, and preparation of financial statements and disclosures, with sign-off on each step. Perform management reviews of financial results, including account analyses, budget-to-actual and period-over-period variances, estimates, and reconciliations, at a defined precision threshold, documenting the investigation and resolution of items exceeding it. Retain review evidence identifying the reviewer, items challenged, and outcomes.
unified · Direct
UC-FIN-03 — Perform and review account reconciliations
Perform account and subledger-to-general-ledger reconciliations for in-scope accounts on a defined frequency, verifying the completeness and accuracy of balances. Require independent, timely review and approval of each reconciliation, and age, track, and resolve reconciling items within defined thresholds. Retain completed reconciliations, approvals, and resolution evidence.
unified · Direct
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 · Direct
UC-FIN-05 — Segregate incompatible financial duties
Divide incompatible duties, including authorization, recording, custody of assets, and reconciliation, among different individuals across financial processes so that no one person can both perpetrate and conceal an error or fraud. Enforce the segregation through role design and system access, maintain a documented segregation-of-duties conflict matrix, and review conflicts periodically with documented mitigating controls where segregation is impracticable.
unified · Direct
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 · Direct
UC-FIN-07 — Control automated processing and resolve exceptions
Configure automated processing controls, including system-enforced calculations, three-way matches, tolerance checks, and other configurable application controls, under documented policies and procedures so transactions are processed completely, accurately, and in the proper period. Generate exception, error, and edit reports from processing, and review and resolve reported items timely with documented disposition. Evidence includes control configurations, configuration change approvals, and exception-report review records.
unified · Direct
UC-FIN-08 — Control interface transfers and output delivery
Control data transferred between systems and delivered as output so that it is complete, accurate, timely, and processed only once, using record counts, control totals, or hash checks reconciled at each interface with automated error handling and alerting for failures. Deliver or make output available in accordance with documented specifications, and investigate and resolve interface or delivery failures timely. Evidence includes the interface inventory, reconciliation results, and failure-resolution logs.
unified · Direct
UC-FIN-09 — Ensure quality of information used in reporting
Define and communicate the information requirements for financial processing and reporting, including data definitions and report specifications. Validate the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting by verifying source data, report logic and parameters, and totals before reliance, and baseline standard reports with revalidation on change. Retain validation evidence for each report relied upon.
unified · Direct
UC-FIN-10 — Safeguard assets and stored financial data
Restrict physical custody of financial assets, negotiable instruments, and accounting records to authorized custodians, and perform periodic counts and inspections reconciled to the accounting records. Store transaction inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications and retention requirements, protecting them against loss and unauthorized alteration. Evidence includes custody logs, count results, and storage and retention configurations.
unified · Context
UC-GOV-01 — Establish and maintain the enterprise governance framework
Design, implement, and maintain an enterprise governance system for information and technology that sets direction, decision rights, and accountability, together with a supporting management framework (organizational structures, policies, processes, and culture) that puts governance direction into operation. Evaluate the effectiveness of the governance and management framework periodically and adjust it as the enterprise context, strategy, and regulatory environment change.
unified · Context
UC-GOV-04 — Set tone at the top: integrity, ethics, and risk-aware culture
Leadership defines and demonstrates commitment to integrity, core ethical values, and the desired risk-aware culture through an adopted code of conduct, consistent leadership behavior, and periodic evaluation of adherence with timely remediation of deviations. Organizational leadership is responsible and accountable for cybersecurity and internal-control risk and fosters a culture that is ethical, risk-aware, and continually improving, with expectations communicated to all personnel and business partners.
unified · Context
UC-GOV-05 — Ensure board-level oversight of risk and internal control
The board of directors (or equivalent governing body), demonstrating independence from management and appropriate expertise, oversees the development and performance of internal control and the cybersecurity risk management program, approving the risk strategy and material policies. The board periodically reviews risk-management outcomes, program effectiveness, and management reporting, and directs adjustments to strategy and direction; oversight activities and decisions are documented in minutes and supporting materials.
unified · Context
UC-GOV-07 — Hold individuals accountable for control responsibilities
Management requires all personnel to apply information security in accordance with established policies and procedures and holds individuals accountable for their internal control responsibilities. Accountability is enforced through defined expectations, documented rules of behavior acknowledged before access is granted and re-acknowledged when updated, performance measures and incentives, and disciplinary consequences for violations.
unified · Context
UC-GOV-08 — Segregate conflicting duties and areas of responsibility
Identify duties and areas of responsibility that conflict — such as requesting versus approving access, development versus production deployment, or initiating versus approving transactions — and segregate them among different individuals or roles. Where segregation is impracticable, apply and document compensating controls such as enhanced monitoring, logging, or independent review.
unified · Context
UC-GOV-09 — Appoint accountable security leadership (CISO)
Designate a qualified senior leader (e.g., a Chief Information Security Officer) with organization-wide responsibility, accountability, authority, and resources to develop, implement, and enforce the information security program, and designate accountable leadership roles for the risk management program. The security leader reports in writing on the program, material cybersecurity risks, and remediation plans to the board or equivalent governing body at least annually.
unified · Context
UC-GOV-11 — Allocate adequate resources and budget for security
Allocate and manage funding, personnel, and other resources commensurate with the organization's cybersecurity risk strategy, roles, responsibilities, and policies, ensuring security and privacy requirements are addressed in capital planning, budgeting, and investment decisions. Periodically evaluate resource allocation and utilization for adequacy and optimization, and adjust budgets as priorities and risks change.
unified · Context
UC-GOV-16 — Select and tailor a risk-based control baseline
Select and document a baseline of security and privacy controls — including general controls over technology — responsive to assessed risks, and tailor it to the organization's environment, complexity, and risk appetite, considering an appropriate mix of preventive and detective control types and segregation of duties. Centrally identify, manage, and deploy common controls where appropriate, and document and approve the rationale for all tailoring decisions.
unified · Context
UC-GOV-18 — Document and approve system security and privacy plans
Develop, approve, and maintain security and privacy plans for systems that describe each system's authorized purpose, boundary, operating context and concept of operations, requirements, and the controls in place or planned. Distribute plans to authorized personnel, protect them from unauthorized disclosure and modification, review them at defined intervals, and update them to address changes — verifying that systems continue to be used only for their intended and authorized purposes.
unified · Context
UC-GOV-20 — Govern data as an asset with accountable oversight bodies
Establish data governance: policies and standards for managing data through its life cycle, and formally chartered governance bodies (e.g., a data governance body and, where required, a data integrity board) with defined membership and responsibilities. These bodies oversee data management, data quality and integrity, and the review and approval of data-sharing and matching agreements, and report on data governance at defined intervals.
unified · Context
UC-GOV-31 — Maintain access control, identity, and personnel security policies
Establish, document, and disseminate policies and procedures governing logical access control, identification and authentication, and personnel (human resources) security — covering authorization based on need-to-know and least privilege, credential and authenticator management, and personnel screening, transfer, and termination requirements. Communicate these policies to the workforce and review and update them at defined intervals and upon significant change.
unified · Context
UC-GOV-37 — Operate insider-threat and threat-awareness programs
Implement an insider threat program that includes a cross-discipline insider threat incident handling team and defined indicators, reporting channels, and response procedures, together with a threat awareness program that shares current threat information across the organization, including with leadership and security personnel. Review the effectiveness of both programs at defined intervals and adjust them to the evolving threat environment.
unified · Context
UC-LOG-07 — Monitor user sessions and personnel activity
Monitor user and administrator activity for signs of misuse: capture and review session activity for defined high-risk circumstances such as privileged or remote sessions, with legal review and any required disclosure to users, and monitor personnel technology usage against acceptable-use expectations to surface potentially adverse events. Restrict access to captured session data to authorized reviewers and involve HR and legal counsel in handling findings.
unified · Context
UC-RISK-10 — Maintain a risk register and report the portfolio view
A risk register records identified risks with analysis results, owners, treatment plans, and current status, and is updated on a defined cycle and upon significant change. Portfolio-level views aggregate risks across the entity and are reported to management and the board to support oversight and resource decisions. Register extracts and portfolio reports evidence operation.
unified · Context
UC-RISK-12 — Assess and mitigate fraud risk including management override
A documented fraud risk assessment considers fraudulent reporting, asset misappropriation, and corruption, evaluating incentives, pressures, opportunities, and rationalizations, and explicitly addresses the risk of management override of controls. Specific anti-override controls operate, including review of journal entries and significant estimates at an appropriate level of precision. The assessment and mitigating controls are refreshed at least annually with documented results.
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
Internal Audit Ethics, Objectivity & Competency Program
Runs on an Audit item created per cycle as the anchor — audit_type=internal, scope set to the IA professional-practice program for the period, period_start/period_end = the cycle window (a program cycle, not an engagement, so this is a documented reuse of the Audit type; it is the "cycle item" every stream links its evidence to and closes at the end). A decision-aware annual cycle that attests the ethics and professional-courage expectations and documents deviations, screens per-engagement conflicts and manages objectivity impairments, collects confidentiality acknowledgments and restricts audit-file access, and assesses competency against role requirements with approved, tracked continuing-professional-development plans for each auditor. It consumes no upstream workflow: prior-cycle carryover (unresolved-deviation and monitored-impairment Issue items still open against the prior cycle's Audit item, plus in-progress development plans) is its own input, and the population is confirmed against the HR roster, engagement staffing, and the audit-file access list before measurement begins. Named deliverables: the professional-practice requirements memo, the ethics attestation register, the conflict-of-interest declarations and impairment register, the confidentiality acknowledgment register and before/after audit-file access review, the competency assessments with coverage matrix and CPD plans, and the signed CAE conformance report to the audit committee — assembled into an indexed cycle evidence file on the anchor Audit item. Downstream is self-feeding: the carry-forward list produced at close hands off to the next run of this same workflow; there is no distinct downstream workflow. In scope: every auditor and assisting party (employees plus co-source, outsourced, and guest auditors) who performed internal audit work or holds audit-file access during the period, across all four expectation streams (ethics, objectivity, confidentiality, competency); out of scope: the audit engagements' own subject-matter conclusions and any HR, legal, or ethics-office investigation a disclosed concern is referred into.
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
Audit Fieldwork, Findings & Reporting
Runs on the existing audit item. Execute approved audit procedures, evaluate and clear observations, issue a supported report, and close the engagement record with tracked actions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 Certification Readiness
Runs on the existing audit item. Assess ISO/IEC 27001 certification readiness across ISMS scope, clauses, risk treatment, Annex A applicability, internal assurance, gaps, and audit-entry governance. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Process Narrative & Walkthrough
Runs on the existing process item. Document an end-to-end process, corroborate the narrative through a representative walkthrough, and approve a traceable current-state record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Fraud Risk Assessment & JE Testing
Runs ON an audit item (an existing engagement). Assesses fraud risks across the fraud triangle and management override, maps anti-fraud controls to those risks, validates and characterizes the journal-entry population for the period, selects entries by pattern flag plus a reproducible random draw from the unflagged remainder, tests every selected entry for support, approval and business purpose, and raises every unsupported anomaly as an issue linked to its FSLI and control. Hands off to engagement reporting for issue disposition and reporting.
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
Substantive Testing & Data Analytics
Runs on an existing Audit engagement (`audit`) already scoped to one or more significant FSLIs; enriches it, never re-creates it. Inputs: the scoped FSLI(s) (`fsli.balance`, `fsli.assertions`, `fsli.significant`) and a source-system extract per population under test. Named deliverables: the validated population record, the reproducible sample draw, the whole-population analytics results, and the FSLI assertion conclusion (`fsli.rationale`). Handoff: fraud risk and journal-entry testing (the fraud-risk-je-testing workflow) once every exception is dispositioned and the assertion conclusion is recorded.
workflow · Context
Internal Audit Engagement Lifecycle
Internal Audit Engagement Lifecycle: run an IIA-aligned engagement on the existing Audit item (audit_type=internal) created by Audit Engagement Planning — it enriches that item and never creates a duplicate; the workflow instance attaches to the Audit item and is archived on it at close. In scope: evidence requests, fieldwork, finding evaluation, supervisory QA, conclusions per objective, and action-plan registration for the auditable entity and period fixed at planning (Audit.scope, Audit.period_start/period_end). Named deliverables: the evaluated findings register (one Issue item per finding), conclusions per objective (recorded on the Audit item as rating/opinion), and the report-ready handoff package. Out of scope: report wording (owned by Audit Report Drafting) and remediation validation (owned by Finding Remediation & Action-Plan Monitoring). It consumes the approved planning handoff package from Audit Engagement Planning and hands off to BOTH downstream workflows — Audit Report Drafting (the findings register and conclusions) and Finding Remediation & Action-Plan Monitoring (the registered action records) — rather than duplicating their work.
workflow · Context
Audit Engagement Planning
Audit Engagement Planning runs ON an already-opened Audit item — the engagement record the annual audit plan created. The audit is an INPUT: this workflow enriches that item, it never creates a duplicate. In scope: producing the planning package — scope, the engagement risk assessment and mapped control population (Risk and Control items linked to the Audit; together the engagement Risk & Control Matrix, the RCM), the sampling plan, the planning memos, and the enriched audit record. Out of scope: fieldwork, findings, and reporting, which belong to the downstream Internal Audit Engagement Lifecycle workflow that consumes this workflow's handoff package (the RCM travels with it). There is no upstream workflow; planning starts from the audit-plan entry itself.
workflow · Context
Quality Assurance & Improvement Program Cycle
Operate the Quality Assurance & Improvement Program (QAIP) cycle: ongoing-monitoring evidence, periodic self-assessment, external quality assessment (EQA) support, improvement planning, and board reporting. This cycle runs on an Audit item created per cycle (audit_type = internal — the schema has no quality_assessment option; scope = "QAIP cycle FYxx"; period_start/period_end span the period under assessment); the workflow instance attaches to that Audit item and every cycle output — the per-standard conformance ratings matrix, the below-GC finding Issue items, the improvement and action plan, and the QAIP results report — links back to it. It consumes the period's existing engagement Audit items and their completed engagement-workflow runs as the population and test evidence, plus the standing QAIP framework, charter, and methodology-manual Policy items. In scope: assessing the internal audit function's conformance with the Global Internal Audit Standards for the period. Out of scope: engagement-level rework — this cycle assesses quality, it does not redo fieldwork, which belongs to the engagement workflows. There is no upstream feeder; this workflow starts the quality chain and hands its approved results — overall conclusion, per-domain ratings, and conformance-statement wording — to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Audit Report Drafting
Runs on the existing Audit using approved fieldwork conclusions, findings and management responses. Produces the audit report after management factual confirmation and independent IA management approval of the exact draft, then the issued report, completion announcement and tenant-bound MAR survey dispatch record for remediation monitoring and QAIP.
workflow · Context
Third-Party Vendor Assurance Engagement
Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.
workflow · Context
Internal Audit Charter, Independence & Board Governance Cycle
Runs on one Audit item created per governance cycle (audit_type: internal; scope set to the internal-audit charter/independence/board-governance cycle for the period) — the workflow instance attaches to that cycle item and writes to it throughout. The internal audit function and its board-approved charter — a Policy item (policy_type: charter) with its own version lineage — already exist and are reviewed, reaffirmed, or amended here, never recreated. The cycle as a decision-aware procedure: the CAE delivers functional reporting to the audit committee, affirms organizational independence in writing and treats any impairment, reviews and reapproves the board mandate and charter with its unrestricted-access provisions, runs the executive session and committee action on the CAE and the plan and budget, executes the stakeholder communication plan, and retains the governance evidence. Consumes upstream: closed assurance-engagement records (Audit items with their linked Issue findings) produced by the individual engagement workflows, the recommendation-tracking register (Issue items), and the prior cycle's carry-forward (open Issue items plus the prior run's carry-forward list). Named deliverables: the CAE functional reporting pack, the written organizational-independence affirmation, the reaffirmed or reapproved audit charter, the audit-committee minutes and resolution records, the stakeholder communication log, and the control-linked governance evidence set. In scope: the board-governance cycle for the internal audit function itself — charter, independence, committee reporting, and stakeholder communication; out of scope: the individual assurance engagements whose results feed the committee report, which run under their own workflows. Terminal by design: no downstream workflow is chained from this cycle; open threads carry forward to seed the next run of this same cycle.
workflow · Context
Annual Internal Audit Planning & Resource Management
Runs the chief audit executive's annual internal audit planning cycle on a per-cycle Audit item created for the year (audit_type=internal, e.g. "Annual IA Planning Cycle FY20XX", status PLANNED→COMPLETE, period_start/period_end = the plan year) — the anchor the workflow instance and every cycle document and link hang off, since no native plan/cycle type exists. It consumes the standing (prior-year) audit universe carried in as Process items plus the prior cycle's archived instance and universe memo, and enriches rather than recreates it: it refreshes the audit universe and the documented understanding of governance, risk, and control processes, ranks the universe by residual risk, develops the internal audit strategy and the risk-based audit plan, resources it with a budget, staffing, and technology plan, tests resource sufficiency, obtains board approval, and reassesses the plan and resources on the quarterly refresh. In scope is the enterprise-level planning cycle from audit-universe refresh through board approval, plus the quarterly plan-and-resource reassessment; delivering the individual engagements is out of scope — the approved engagement list (the created engagement Audit items) hands off to each engagement's own audit engagement planning workflow.
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
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
SOC 2 Readiness & Evidence Collection
SOC 2 Readiness & Evidence Collection runs ON an already-opened Audit item — the SOC examination engagement record (audit_type readiness, or external_attestation) whose scope (report type and Type 1/Type 2), examination period (period_start/period_end), and CPA firm (external_firm) are already set. That Audit item is an INPUT: this workflow enriches it and attaches its run to it, never creating a duplicate engagement. It consumes the organization's own Control library — the Control items, framework tagged soc2/soc1 — and no upstream workflow feeds it. In scope: one SOC examination cycle end to end — map the Control library to each in-scope Trust Services criterion (Security always; Availability, Confidentiality, Processing Integrity, or Privacy only where a customer commitment requires it) and SOC 1 control objective, close readiness gaps, run the provided-by-client (PBC) evidence request list with QA, and coordinate the CPA firm through fieldwork and follow-ups. Named deliverables: the criteria-to-control mapping matrix and graded gap matrix, the owned PBC evidence request list, the QA'd evidence set, and the cross-referenced PBC response package — all attached to the anchor Audit and its workflow instance. Out of scope: the SOC report the CPA firm drafts and continuous control monitoring between examinations. No downstream workflow is declared; this run's next-cycle seed artifacts (the PBC list and control calendar) stay on the close step as the de facto handoff to the next examination.
workflow · Context
Joiner-Mover-Leaver Access Lifecycle
Run one instance per HR-triggered joiner, mover, or leaver event as a decision-routed access-lifecycle control that enriches the EXISTING Control item for JML / user-access provisioning-deprovisioning (control library, domains=access_control_identity, framework nist-800-53 + iso-27001) - attach the instance to that control, never create a duplicate. Consume the authoritative HR event record from the external HR system of record (the trigger): classify the event, then provision role-based access, adjust with SoD checks on transfer, or evidence timely removal on exit, and file the named audit-ready access-lifecycle evidence package before closing. In scope: identity-provider, directory, HR-system, ERP, and connected-SaaS entitlements for the affected worker. Out of scope: HR record creation itself, physical-security badge policy, and system-owner entitlement design. The run is terminal - no upstream or downstream AssureSwarm workflow: it starts from the external HR event and ends at the archived evidence package attached to the Control item. The anchor Control links (item relationship) to the access Risk it mitigates.
workflow · Context
CSF 2.0 Profile & Maturity Assessment
Runs on an Audit item created for this assessment cycle (audit_type = readiness) — the CSF assessment engagement the workflow instance attaches to and enriches as it progresses (scope, period, rating, and report fields are written on that Audit item; every in-scope Control is linked to it so the controls-scoped profile is queryable). Build, against that boundary, a NIST CSF 2.0 Current Profile, a Target Profile, an organizational Tier rating, a subcategory gap analysis, and a CISO-ready remediation roadmap. The workflow originates on its own — scoping ingests prior CSF profiles and open POA&M (Issue) items as data, not as a named upstream handoff. In scope: rating the in-scope control set against the CSF 2.0 Core, setting target outcomes, assigning a Tier, and producing a prioritized roadmap. Out of scope: executing the remediation projects themselves and re-performing independent assurance testing. The named deliverable is the assessment package (profiles, gap analysis, Tier, posture report, roadmap, closure artifact), handed off to TWO downstream workflows that consume it rather than repeat the profiling: the Cybersecurity Assurance Review (always) and the AI Governance & Risk/Impact Assessment (only when AI systems fall inside the boundary).
workflow · Context
Threat Intelligence & Insider Threat Program
Runs on the existing Process item "Threat Intelligence & Insider Threat Program" (process_type=security_process, process_owner = program lead) — a long-lived program record related to the Control items it operates (UC-RISK-17, UC-BCDR-16, UC-GOV-37); each cycle is one recurring workflow instance attached to that Process, enriching the standing program rather than creating a new one. Decision-aware, covering NIST SP 800-53 PM-12, PM-16, and RA-10 and NIST CSF 2.0 ID.RA and DE.CM. In scope: cyclic intake and curation of threat intelligence into a validated intake register and intel cards, governed internal dissemination and TLP-marked outbound sharing packages, intel-driven threat hunts (producing the hunt summary) and any resulting investigation record, and privacy-guarded review of insider-threat indicators with a governed board disposition and a restricted insider case file, closing with a program-effectiveness report and a reperformable cycle archive. No upstream workflow feeds it; the only cross-run input is the prior cycle's carry-forward package (the carry-forward document from the previous instance's program-effectiveness report step, which closes each cycle), and each cycle emits the next one. Out of scope and handed off only in prose (no terminal handoff node): incident-response execution (the incident-response process, once an incident is declared at open-investigation) and HR/legal employment actions (owned by those functions within an insider case). Each cycle's intel-and-hunt track and its insider-threat track start in parallel from their own inputs.
workflow · Context
System Categorization, Security Planning & Authorization
Operator workflow for the system owner and authorizing official to categorize a system by impact and criticality, maintain the approved system security and privacy plan, authorize internal connections, and grant and track authorization to operate, as a decision-aware flow with categorization-approval and authorization branches. In scope: a single system — its impact and criticality categorization, the system security and privacy plan, internal-connection authorization, and the authorization-to-operate decision with reauthorization tracking. Out of scope: the control assessments and testing that feed the authorization risk view (consumed as an input) and enterprise categorization-policy setting; there is no upstream or downstream workflow, so any cross-workflow dependency is declared as a step input rather than routed.
workflow · Context
Information Security Program Governance Review
Standing operator workflow for the CISO's quarterly information security program governance review and its annual leg. Each cycle runs as one workflow instance attached to the existing "Information Security Program Governance" Process item (process_type: security_process, owner CISO), with the four governing Control items UC-GOV-06/09/10/15 linked to it. It is a decision-aware flow that enriches — never recreates — the senior-management-approved information security program plan (held as a Policy item) and the current role assignments every cycle, and branches into the written board report, workforce competency review, and plan reapproval when the annual interval or a significant change requires it. Named deliverables: the reapproved information security program plan (the Policy item, re-versioned and re-signed), the roles-and-authorities register, the annual written board report to the governing body, and the workforce competency review — each retained on the workflow instance. In scope: the program plan, security roles/authorities/reporting lines, the annual board report, and workforce competency for this organization; out of scope: executing the underlying protective controls and enterprise ERM governance, which are owned by their own workflows (coso-erm is referenced here only for oversight-of-design of the governance structure). There is no upstream or downstream workflow handoff — this cycle is genuinely self-contained: it starts from its own cadence trigger, consumes its own prior-cycle governance record, and seeds the next cycle at close.
workflow · Context
Security Policy Suite Review
Standing operator workflow for the security policy owner's annual (and change-triggered) review, redline, reapproval, and dissemination of the full security policy suite -- secure acquisition/development/configuration-management/maintenance, asset/media/physical protection, access/identity/personnel security, communications/cryptography, security awareness and cyber-hygiene, audit-logging/monitoring/system-integrity, contingency planning and disruption mitigation, and incident response. Anchor: each run is a workflow instance attached to the existing "Security Policy Management" Process item (process_type=security_process, process_owner=policy owner, frequency=annual) -- that instance IS the cycle record the tracked review items roll up to; the eight policy families are the existing Policy items the cycle enriches (never recreates). In scope: reviewing each Policy item against current risk and threat inputs, consolidating findings into one suite-level revision disposition, routing redlines to the right stakeholders, reapproving under accountable security leadership (writing Policy.approved_by / version / effective_date / next_review_date back onto each policy), and tracking dissemination and workforce acknowledgment as a single evidence set. Out of scope: authoring net-new policy domains and operating the technical controls the policies govern. The workflow has no upstream feeder workflow -- its inputs are the policy register (the eight Policy items), the prior-cycle workflow instance and its exported operating record, and the annual review calendar carried on Policy.next_review_date -- and no named downstream workflow; open corrective actions (Issue items) carry forward as explicit inputs to the next cycle. The eight domain reviews run in parallel and converge on a single revision-disposition decision.
workflow · Context
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
Control Design
This instance runs against the Control item it creates: drafted at the objective step and committed to the Risk & Control Matrix (RCM) at record-the-control, so the archived instance is that control's design audit trail. It consumes no upstream workflow — a control is motivated by an existing Risk item or an audit Issue (finding/deficiency), which it links to rather than rebuilds. Design one new control end to end: control objective and attributes, risk mapping to the register, evidence and test-approach design, RCM record creation, disposition, packaging, and archival. The named deliverable is a new, uniquely identified control record in the RCM (a Control item) carrying a design determination statement, plus its test plan. In scope: designing and recording a single new control so it is operable and testable. Out of scope: executing the control's operating-effectiveness tests and remediating deficiencies, which are handed off downstream to the Security Control Assessment & POA&M Remediation workflow.
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
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
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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
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
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
Control Design Assessment
Runs on the existing control item. Assess whether a control is clearly specified and designed to address its stated risk before deciding what follow-up or testing is appropriate. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Exception Evaluation and Remediation
Runs on the existing control item. Validate a control-test exception, evaluate its scope and implications, determine disposition, and establish accountable remediation where needed. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Remediation Retest and Closure
Runs on the existing control item. Verify remediation readiness, independently retest the changed control, evaluate sustained results, and approve a supported closure decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Walkthrough
Runs on the existing control item. Walk one representative transaction or event through the control to understand actual execution, evidence, handoffs, and changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 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
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
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
Interim Operating Effectiveness Testing
Runs on the existing SOX Audit using approved Control-hosted TOD/TOE results and the interim scope. Produces the program coverage and exception register, remaining-period commitments, all-controls auditor handoff and management status communications for year-end roll-forward.
workflow · Context
Period-End Roll-Forward Testing
Runs on the existing SOX Audit using approved interim results and remaining-period commitments. Produces independently reviewed year-end coverage, a separate Year-end Management Inquiry Package and the full-year conclusion for audit reporting and deficiency aggregation.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
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
Quarterly Board & Audit-Committee GRC Reporting
Runs on the existing standing "Board & Audit-Committee GRC Reporting" governance Process item (process_type=business_process, frequency=quarterly): one workflow instance per quarter attaches to that Process and enriches it (the Process is not created here), and each closed instance is the prior-quarter baseline for the next run. The named deliverable is the quarterly board & audit-committee GRC pack (six-domain narrative deck, Word + PDF, redaction-cleared). It compiles that pack across six domains — risk profile, control health, open issues, regulatory deadlines, audit-plan progress, and SOX posture — computed over one quarter window. In scope: aggregating and synthesizing existing GRC records (Risk, Control, Issue, Audit, and Control-hosted SOX testing workflows) into a board-level narrative, obtaining executive and committee approval, and archiving the decision and action register. Out of scope: performing the underlying risk assessments, audits, or control tests themselves. Consumes two upstream handoff packages: the Enterprise Risk Assessment & Portfolio Oversight Cycle package (risk register, residual scores, appetite positions) and the Audit Report Drafting & Regulatory Compliance Attestation Cycle package (audit-plan status, issued reports, attestation status); there is no downstream workflow — the closed package feeds the next quarterly run of this workflow.
workflow · Context
Risk Appetite Definition & Board Reporting
Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.
workflow · Context
Risk Register Intake
Intake one newly identified risk into the enterprise register. The instance creates a new Risk item at the first step and attaches to that Risk item for the whole run — every rating, control link, and disposition enriches that single record. It consumes the initial risk identification (no upstream workflow) plus existing Control items, Policy items, and evidence carried on Issue, Audit, and Control-hosted SOX testing workflows, and produces the named deliverable: a review-ready risk intake package attached to the Risk item. On completion it hands that package to the Enterprise Risk Register Lifecycle workflow for ongoing monitoring. In scope: intake and initial assessment of one new risk. Out of scope: portfolio-level aggregation, periodic re-assessment, and risk-treatment project execution, which the Enterprise Risk Register Lifecycle workflow owns.
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
Board Risk & Internal Control Oversight Cycle
Board Risk & Internal Control Oversight Cycle as a decision-aware workflow: the governance office verifies board independence and expertise, compiles the board risk & internal-control oversight pack, routes the at-least-annual governance-framework effectiveness evaluation, facilitates the independent board's approval of the risk strategy and material policies, captures and minutes the directed adjustments, and launches and tracks them as an owned open directives register. It is standalone: the governing body and the governance framework are not Studio item types, so there is no natural item anchor — each cycle runs as a fresh recurring workflow instance and its deliverables attach to the run's own steps. The named deliverables are the composition-and-independence summary, the board risk & internal-control oversight pack, the annual governance-and-management-framework effectiveness evaluation when in scope, the adopted board/committee minutes, and the board directives-and-adjustments register (one Issue item per directive, linked across cycles). The risk strategy and material policies the board approves are Policy items (approved_by, version, next_review_date); board directives, approval conditions, and framework adjustments are Issue items (issue_type: observation, source: management_identified). In scope: a single named governing body's quarterly (or specially convened) risk and internal-control oversight meeting and, where the annual clock or a substantial-change trigger applies, that cycle's enterprise governance and management framework effectiveness evaluation. Out of scope: the day-to-day first- and second-line control operation, testing, and assurance that feed the pack — no workflow hands into this cycle, and the board's directives flow onward into control-remediation and policy-update execution as prose, not a wired downstream template.
workflow · Context
Code of Conduct & Workforce Accountability Cycle
Code of Conduct & Workforce Accountability Cycle as a decision-aware workflow that runs on an existing ethics Process item ("Ethics & Code of Conduct Program", process_type: business_process, frequency: annual): each annual cycle is a workflow instance attached to that Process, and the archived instances on it ARE the ethics register - version history plus the open-deviation log. The code of conduct and the rules of behavior are Policy items (policy_type: policy and procedure) enriched each cycle - never recreated - and the tone-at-the-top and acknowledgment Controls (UC-GOV-04, UC-GOV-07) are linked to the Process via item relationships. The cycle reissues the code and rules of behavior, secures leadership adoption, communicates expectations to personnel and business partners, gates access on acknowledgment, and evaluates adherence - routing violations through the documented disciplinary process and remediating deviations timely, with deviations and violations recorded as Issue items carrying the full remediation lifecycle. Named deliverables: the reissued code of conduct and rules of behavior (Policy items plus redline/change summary), the leadership adoption decision, the acknowledgment coverage report with access-gating evidence, the deviation and violation inventory (Issues), the disciplinary and remediation outcomes, and the archived self-contained cycle evidence package. In scope: one annual accountability cycle (a full reissue or an update-driven re-acknowledgment) covering all in-scope personnel and the business-partner populations bound by the code. Out of scope: the ethics-hotline intake that feeds reported concerns - an input, not a step here. No upstream workflow is required to start the cycle; it is triggered by its annual cadence or by a material change to the code or rules of behavior. Downstream, the operational access-provisioning system consumes this cycle's acknowledgment gate - the workflow's terminal handoff - before it grants access.
workflow · Context
Technology Investment & Project Risk Governance
Technology Investment & Project Risk Governance as a decision-aware checkpoint graph, run as a recurring workflow instance attached to the existing Process item for the technology-investment / portfolio-governance process (process_type: business_process) — each quarterly board cycle enriches that standing process record rather than creating a new one. In the cycle the investment board refreshes its criteria, scores and prioritizes the technology and innovation portfolio, routes the annual capital-planning leg that allocates security funding to the risk strategy, monitors in-flight value and reprioritizes or terminates where value is not realized, and enforces security-risk sections in every project gate with ERM-linked artifacts. In scope: the quarterly technology investment-board review (always), the annual capital-planning and security-budget leg (when the funding and staffing envelope must be set or re-planned this cycle), and every project stage gate falling due. Out of scope: individual project execution and delivery mechanics and day-to-day security operations. The cycle consumes the ERM cyber-risk register (Risk items, category: cyber_security) and the approved program business cases as standing inputs, and produces a board decision record and evidence pack as its named deliverable. There is no downstream workflow hand-off, so cross-references are recorded as linked records (Issue ↔ Risk) rather than routed onward; the scored portfolio, in-flight programs, and stage-gated projects have no native item type and live as step documents.
workflow · Context
Data Governance Council Operations
Data Governance Council Operations as a decision-aware workflow. Each quarterly cycle runs as one workflow instance attached to the existing UC-GOV-20 Control item (data governance council oversight; domains=governance_policy_oversight, frequency=quarterly) — it enriches that Control as its execution record and never creates a governing body. It validates the chartered council's charter and membership, runs the annual policy and lifecycle-standards review when due, compiles data-quality and integrity metrics, reviews and approves data-sharing and matching agreements, convenes the council with recorded minutes, and reports data governance status at the defined interval. Upstream, it consumes the prior cycle's archived governance record — the council and data-integrity-board charters (Policy items, policy_type: charter) and membership rosters, the current data-governance policy and data-lifecycle standards library (Policy items), the prior minutes and status report, and the open action-item register (Issue items linked to the Control). Named deliverables: the data-quality and integrity dashboard, the data-management oversight summary, the chair-approved council (and integrity board) minutes, the per-agreement dispositions, and the data-governance status report; the annual branch adds the refreshed policy and standards redlines and the charter and roster amendments. In scope each quarterly cycle: the named business units and data domains, the data governance council (always), and the data integrity board wherever data-matching (Privacy Act computer matching) or new data-sharing requires its review; a metrics-only cycle need not convene the integrity board. Out of scope: bodies and data domains not named in the cycle's scope. Downstream the workflow is self-contained — no separate workflow depends on it — but it chains cycle to cycle: this cycle's archived governance record, filed with the status report, is the next quarterly instance's primary input.
workflow · Context
Enterprise Risk Treatment Operations Cycle
Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.
workflow · Context
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
Risk & Control Self-Assessment (RCSA) Program
Risk & Control Self-Assessment (RCSA) Program as a modular, decision-aware workflow. Each wave runs on its own Audit item — created per wave (audit_type: operational; period_start/period_end = the wave window; report_date = the risk-committee date) — with the workflow instance attached to that item and the wave's questionnaires, attested returns, and calibration record kept inside the run. Each wave rebuilds the assessment universe from the existing Process, Risk, and Control items and their owners (enriching them, never recreating them), issues rating questionnaires to named control and process owners, collects attested self-assessments with structured exception capture, chases completeness, subjects the results to second-line challenge and calibration, aggregates a residual-risk view across units, updates the risk register's residual ratings, and routes self-identified issues to remediation and exceptions to time-bound acceptance before the results reach the risk committee. In scope: first-line self-assessment of in-scope business units and shared functions against their own risks and controls. Out of scope: independent testing/audit of those controls, and the remediation and formal risk-acceptance of what the wave surfaces, which are handed off downstream to the Finding Remediation & Action-Plan Monitoring (deficiencies), Policy Exception & Risk Acceptance (risk-acceptances/waivers), and Quarterly Board & Audit-Committee GRC Reporting (the wave report) workflows.
workflow · Context
Control Library Lifecycle
One control, one record: intake, author, classify, link, publish, review, retire — the library that audit RCM and SOX scoping read from.
workflow · Context
ERM Risk Identification & Register Refresh
Runs on the existing risk item. Run a periodic enterprise risk identification cycle, consolidate candidate risks, and approve the resulting register changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Enterprise Risk Register Lifecycle
Enterprise Risk Register Lifecycle as a decision-aware workflow. This is a standalone recurring instance (quarterly or annual) that runs against the existing Risk item population — the enterprise risk register itself — enriching those Risk items in place rather than recreating a register: per-risk results are written onto the individual Risk items, and cycle-level deliverables attach to the workflow instance's steps. In scope: maintaining the register across the confirmed entities, business units, and risk-taxonomy categories for this cycle — intake and deduplication of new risks, Three-Lines ownership, control and assurance mapping, KRIs, periodic review and escalation, and retirement. Out of scope: any entity, unit, or category not named in this cycle's confirmed scope. It consumes the candidate-risk handoff package from the upstream Risk Register Intake workflow and hands its maintained register, residual positions, and escalations to two downstream workflows — Enterprise Risk Assessment & Portfolio Oversight Cycle (the maintained register, the concentration and correlation flags, and the residual positions) and Risk Appetite Definition & Board Reporting (the above-appetite entries, the escalations, and the acceptances) — rather than duplicating repeated work.
workflow · Context
Framework Adoption & Cross-Mapping
Adopt or refresh a security/compliance framework (for example NIST CSF 2.0, ISO/IEC 27001:2022, or SOC 2) by scoping the target framework, rating the current profile, defining the target profile, crosswalking requirements to existing controls and adjacent frameworks, prioritizing gaps, and maintaining a live mapping table. The workflow instance runs on an Audit item created at the start of each adoption cycle (audit_type: readiness, or compliance) — its scope/period fields carry the assessment boundary and cycle window, and every step document versions against it. No upstream workflow feeds this one; it consumes the organization's own existing inventory: the risk register (Risk items), the control library / RCM (Control items and their Risk links), the in-scope Process inventory, and any prior Audit items for this or adjacent frameworks. Named deliverables: the framework mapping table (the crosswalk), the risk-ranked prioritized gap list, the coverage/gap dashboard, and the versioned adoption package. In scope: profile construction, crosswalk mapping, gap prioritization, and the closure disposition. Out of scope: authoring the policies and designing the new controls the gaps demand — those are handed off downstream to TWO workflows, Policy Lifecycle Management (policy-driven gaps) and Control Design (control-build gaps).
workflow · Context
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
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
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
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
workflow · Context
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
Fraud Risk Assessment & Anti-Override Control Review
Runs on an Audit item created for the cycle (audit_type internal or sox_testing; scope = "Annual fraud risk assessment & anti-override review FYxx"; period_start/period_end = the assessed period). The workflow instance attaches to that Audit, which is the cycle's durable record - a fresh Audit per cycle keeps successive years separable; the workflow enriches it, it does not create a duplicate. Covers the fraud triangle across fraudulent reporting, asset misappropriation, and corruption, the explicit assessment of management override risk, anti-override control recalibration (journal-entry review criteria and significant-estimates scrutiny), and audit committee reporting. Consumes upstream: the prior-period fraud risk register (Risk items, category financial_reporting, with their inherent_rating/residual_rating/treatment and dispositions) as the baseline; the SOX-scoped Process population; in-period Issue signals (deficiencies, findings); and the existing Control inventory - specifically the journal-entry-review and significant-estimates-challenge Control items whose description/frequency/control_owner hold the current criteria. In scope: the current SOX-scoped entity and process population, judged against the prior-period baseline; an event-triggered refresh scopes to the affected entities and fraud vectors, not automatically the whole map. No upstream workflow feeds this cycle - it originates from the prior-period assessment and interim events since. Named deliverable: the fraud risk assessment report and the audit committee package (fraud risk register, heat map, the explicit management-override determination, and the recalibrated anti-override control specification). Hands off to the journal-entry-review and significant-estimates control operators, who run the recalibrated anti-override controls; accepted residual risks persist as Risk items (treatment accept) that seed the next annual cycle's baseline.
workflow · Context
Financial Controls Policy & Segregation-of-Duties Governance
Financial controls policy and segregation-of-duties governance as a decision-aware workflow covering annual policy-suite reapproval and communication, quarterly SoD conflict-matrix refresh, role and system-access conflict screening, mitigating-control documentation, and owner-assignment confirmation, closed out with a control-indexed certified evidence package. Each run is one workflow instance on the existing Process item "Financial Controls Policy & SoD Governance" (process_type: financial_reporting, quarterly cadence), enriching — never recreating — the financial-control Policy suite (entity-wide ITGC and period-end financial reporting oversight policies held as Policy items) and the existing Control items UC-FIN-01 and UC-FIN-05 that the cycle operates. In scope: reapproval and communication of the Policy suite and segregation-of-duties screening across the in-scope entities, finance systems, and personnel, with the cycle running either annual policy reapproval plus the quarterly SoD review or the quarterly SoD review alone; out of scope: access provisioning and remediation execution themselves. As a standing governance control it takes no upstream workflow feed and runs on its own annual/quarterly cadence, but it hands off the remediation and deficiency Issues it raises — elimination-path access conflicts and recorded deficiencies — to the access-management and deficiency-evaluation processes that execute them.
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
Physical Asset Custody & Count Program
Physical-asset custody and count program as a decision-aware workflow that operates control UC-FIN-10 (physical asset custody & count) each cycle. The instance attaches to the EXISTING UC-FIN-10 Control item — a preventive, physical control run on the standing count calendar — enriching that control's operating history each cycle rather than creating a new record; every variance, custody exception, storage gap, deficiency, and carry-forward it raises is an Issue linked back to that Control. It covers count-package preparation, blind physical count and inspection, book reconciliation, custody-log authorization review, storage and retention verification, and certified, audit-ready evidence archival. In scope each cycle: cash funds (petty cash, tills, vault), negotiable instruments on hand, and physical accounting records under retention, counted against the standing count calendar. It consumes no upstream workflow and hands off to none; cross-cycle continuity is item-based — this cycle's carry-forward Issue items become the next cycle's scoping inputs — so there is no handoff package.
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
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
Quarterly 302/906 Sub-Certification Cascade
Quarterly 302/906 sub-certification as a modular, decision-aware workflow: it maintains the certifier hierarchy, refreshes the questionnaire for new systems, reorgs, known control issues, and pending deficiencies, launches the tiered cascade, tracks completion and cures gaps at the cutoff, triages exceptions and qualifications with escalation to the disclosure committee where material, summarizes the population for principal-officer 302/906 sign-off, and archives the certification evidence with the period's support. The instance runs against a campaign-record Audit item created for the quarter (audit_type: compliance; period_start/period_end = the quarter; scope = the in-scope entity and process population), enriching that one record — every questionnaire form, certification register, decision form, dashboard, and attestation package hangs off it and the run's own instance is the audit trail. It consumes the in-scope Process items (each carrying its process_owner) and the open deficiency Issue log, originates on its own recurring quarterly cadence with no upstream handoff, and hands its deficiencies downstream as linked Issue items into the SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows. In scope: the quarter's in-scope entities and processes per the current consolidation scope, from process-owner sub-certification through principal-officer 302/906 sign-off and archival, back-planned from the SEC filing date. Out of scope: the officers' external SEC filing mechanics, and the deficiency, year-end aggregation, and board reporting handled by the downstream SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows this cascade routes into.
workflow · Context
Control Interim Testing Record
Runs on the existing control item. Test a defined interim-period population using a documented sampling and attribute plan, then record exceptions and a bounded conclusion. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Period-End Roll-Forward / Rollover Testing
Runs on the existing control item. Bridge an approved interim control test through period end by assessing change, remaining occurrences, incremental evidence, and unresolved exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Control Testing
Runs on an existing SOX-applicable Control under a sox-testing template. SAMPLE reviews history, attributes and reproducible selection; TEST reviews evidence, exceptions and the approved result artifact. Keep fiscal year on Workflow.customFields.sox.fiscalYear and hand the published result to the SOX program.
workflow · Context
External Audit Support & PBC
Runs on the existing audit item. Govern external-audit PBC requests from intake and preparation through quality review, secure delivery, clarification, and complete request closure. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Process Walkthrough & Design Assessment
Runs on the existing process item. Perform a SOX process walkthrough, update the ICFR narrative and control mapping, and document design observations for management follow-up. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX IPE Validation
SOX IPE Validation as a modular, decision-aware workflow that runs on — and enriches — the existing relying Control item (a key control, framework⊇sox) whose evidence depends on an Information Produced by the Entity (IPE) report: the report's identity, test history, and C&A test date are recorded onto that control rather than into a separate record. In scope: the completeness-and-accuracy conclusion for one IPE report for one period. It consumes its starting key-control population from the upstream SOX scoping / RCM build — the Control library with its Control ↔ Risk links. Its named deliverables are a reperformable completeness-and-accuracy (C&A) memo attached to the control and a validated-IPE evidence-and-decision package. Out of scope: testing the relying control's own operation — that belongs to the downstream SOX Key Control TOD/TOE Test, which anchors on the control's fiscal-year Control-hosted SOX testing workflow and cites this workflow's C&A package instead of re-validating. It can stand alone, but hands its validated-IPE package to SOX Key Control TOD/TOE Test instead of duplicating repeated work.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control TOD/TOE Test
Runs directly on an existing SOX-applicable Control for the fiscal year, using the approved walkthrough, scope, methodology and evidence. Produces an independently approved TOD memo before sampling, period-specific TOE results and reviewed exception evidence for interim/year-end assessment and deficiency remediation. Require that the Control fields.sox_applicable value is the literal boolean true; use Workflow.customFields.sox.fiscalYear for the cycle. TOD/TOE test periods remain step-level facts.
workflow · Context
SOX Process Walkthrough
Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control Operation (Close Cycle)
Runs against the existing Financial Close **Process** item (process_type: financial_reporting, monthly) — one workflow instance per close period that operates that period's SOX key controls and is archived when the control owner's sub-certification closes the period, as the period's durable, control-indexed evidence trail; it enriches the standing Process and Control records, never recreating them. Consumes upstream: the in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) produced by the *Annual ICFR Scoping & Risk Assessment* workflow and linked to this Financial Close Process — plus the prior period's carry-forward **Issue** items (aged reconciling items, approved carryovers). In scope: the close-cycle key controls operating each period — account reconciliations, management review controls, and journal-entry approval — scoped against the period-end close boundary. Named deliverables: the period IPE log, the signed account reconciliations, the completed MRC checklists, the journal-entry approval register, the control-indexed period evidence package, and the control owner's signed sub-certification (supporting the officers' Section 302 certification). Downstream handoff: the archived evidence package and control execution log stand as the sampling population for the *SOX Key Control TOD/TOE Test*; escalated potential deficiencies continue in the *Year-End Deficiency Aggregation & Severity Evaluation* (deficiency-evaluation) track. Out of scope: deficiency severity evaluation and TOD/TOE testing themselves, both of which consume this cycle's archived evidence.