SOX / PCAOB (ICFR)
131 records. Direct records match this source; context records explain their connections.
Read the first JSON page · Data retrieval guide
Mappings may provide partial coverage. Read mapping properties, residual requirements and source notes before relying on a connection.
control · Direct
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 · Direct
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 · Direct
ELC-IC — Information & Communication — quality of financial reporting information, internal communication of control responsibilities, and external communication channels (including whistleblower/ethics hotline).
Information & Communication — quality of financial reporting information, internal communication of control responsibilities, and external communication channels (including whistleblower/ethics hotline).
control · Direct
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 · Direct
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 · Direct
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 · Direct
ELC-RA — Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
control · Direct
ITGC-AC — Access to programs and data — logical and physical access security: authentication, authorization, user provisioning/deprovisioning, periodic access recertification, privileged/administrative access, and segregation of duties enforced via access.
Access to programs and data — logical and physical access security: authentication, authorization, user provisioning/deprovisioning, periodic access recertification, privileged/administrative access, and segregation of duties enforced via access.
control · Direct
ITGC-CM — Program change management — changes to applications, databases, and infrastructure are requested, authorized, tested, approved, and migrated to production by appropriate personnel with segregation between development and production.
Program change management — changes to applications, databases, and infrastructure are requested, authorized, tested, approved, and migrated to production by appropriate personnel with segregation between development and production.
control · Direct
ITGC-DEV — Program development / SDLC — new systems and significant implementations are designed, developed, tested, approved, and converted/migrated in accordance with management's specifications.
Program development / SDLC — new systems and significant implementations are designed, developed, tested, approved, and converted/migrated in accordance with management's specifications.
control · Direct
ITGC-OPS — Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
control · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Context
Excessive privilege and wrong assignment of access rights
Overly broad or wrongly assigned access rights, applications/services running with excessive privileges, and failure to enforce least privilege — a compromise or insider then gains broad access to systems and data.
risk · Context
Abuse of rights, forged rights, and repudiation of actions
Authorized users or administrators exploit legitimate access beyond permitted scope, fabricate or forge credentials/rights to gain privileges, and repudiate performed actions — undermining accountability and audit-trail integrity.
risk · Context
Weak account provisioning/de-registration and access review
No formal user registration/de-registration procedure and no periodic access-rights review, so orphaned or excessive accounts accumulate and access is not revoked when roles change or personnel leave.
risk · Context
Unauthorized use of equipment and unauthorized access escalation
Use of systems, networks, or devices without authorization, and users with authorized access reaching resources that exceed their authorization, potentially to exfiltrate data or conduct attacks.
risk · Context
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · Context
No acceptable-use policy for messaging and telecoms
Because acceptable-use policies for email, messaging, and telecommunication services are absent, personnel use insecure channels without guidance, so sensitive information is inadvertently or deliberately disclosed through unsanctioned communications.
risk · Context
IT resilience failure — unplanned outage, data loss, slow recovery
Critical technology infrastructure or applications experience unplanned outages, data loss, or prolonged recovery times — including failure of DR systems to activate — disrupting operations and harming stakeholders.
risk · Context
Absent or untested business continuity / disaster recovery plan
No BCP/DR plan, or plans that exist but have never been exercised end-to-end, so a natural disaster, pandemic, civil unrest, or infrastructure failure disables critical processes with no tested recovery path.
risk · Context
Poor configuration management and insecure baseline drift
Without documented, enforced baseline configurations and change control, systems drift into insecure states, contain unauthorized changes, or expose unnecessary network services, expanding attack surface.
risk · Context
Absent or weak change-control procedures
Changes to systems, software, hardware, or configurations without formal approval and testing (including unauthorized or poorly tested hardware/config changes) introduce new vulnerabilities, instability, or failed releases.
risk · Context
Attacks by capable, motivated threat actors
Because capable, motivated threat actors - outsiders, privileged and non-privileged insiders, organized groups, competitors, malicious partners or suppliers, and nation-states - actively target the organization's cyber resources, deliberate attacks are attempted against its systems and data, resulting in compromise, disruption, or theft when defenses are outmatched.
risk · Context
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 · Context
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 · Context
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 · Context
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 · Context
Overstatement of assets/revenue (existence & occurrence)
Revenue, receivables, inventory, capitalized assets, prepaid expenses, treasury investments, or tax assets recorded without underlying existence or occurrence — inflating the balance sheet and income statement.
risk · Context
Financial-statement fraud and management override
Intentional misstatement through fictitious revenue, phantom inventory/assets, ghost-employee payroll, or management override of controls — inflating results and deceiving investors and regulators.
risk · Context
Ineffective ICFR / undisclosed material weakness
Because internal control over financial reporting is not maintained effectively - material weaknesses undetected or undisclosed and certifications signed despite known deficiencies - financial statements may be materially misstated and filings delayed or restated, resulting in SEC enforcement, delisting, securities-fraud liability, and loss of investor confidence.
risk · Context
Manual journal entries and management-override risk
Manual/automated journal entries posted with transposition errors, wrong account codes, or amounts; recurring entries not updated; and top-side entries used to override controls and manage earnings at period-end.
risk · Context
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 · Context
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Context
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 · Context
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
risk · Context
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 · Context
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 · Context
Liquidity, capital-structure and refinancing risk
Cash-flow shortfall from working-capital deterioration, covenant breaches accelerating debt, loss of revolving credit, or capital-market disruption; debt maturity walls and downgrades limiting refinancing at acceptable terms; insufficient capital to absorb losses.
risk · Context
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Context
Unauthorized activity — rogue trading, position mismarking, concealment
Losses from transactions not reported or of an unauthorized type, deliberate mismarking of positions, fictitious trade bookings to conceal losses, and circumvention of position/risk limits without disclosure (e.g. rogue trader).
risk · Context
Inadequate board and management oversight of risk and control
Because board and management oversight of risk and control is weak - unclear tone at the top, ineffective board composition or independence, poor committee structure, and limited senior-management commitment - control priorities are not enforced and resources are withheld, so risks accumulate unmanaged and control failures go uncorrected across the entity.
risk · Context
Weak internal control environment enabling fraud and error
Because the internal control environment is weak - segregation of duties absent, authorization frameworks inadequate, and tone at the top poor - fraudulent and erroneous transactions can be initiated and concealed, resulting in material misstatement and financial, regulatory, and reputational loss.
risk · Context
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 · Context
Erosion of individual trust and confidence in data practices
Systemic failure to meet reasonable privacy expectations undermines confidence in products and institutions, causing disengagement, reputational damage, and reduced adoption — an organizational as well as individual harm.
risk · Context
Brand and reputational crisis
Product-safety/quality failures, executive misconduct, data breaches, adverse media, or viral social-media/activist campaigns erode customer trust, investor confidence, partnerships, and brand equity — with long-term value loss exceeding near-term financial impact.
risk · Context
Stakeholder trust and social-license erosion
Gradual loss of trust and social license among customers, employees, investors, regulators, and communities — from perceived values misalignment, poor ESG/governance conduct, or repeated service failures — weakening stakeholder relationships and long-term enterprise value even absent a single acute crisis.
risk · Context
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Context
Applications running with excessive privilege / insecure design
Applications or services running under privileged accounts, opening unnecessary network connections, or lacking secure-by-design architecture mean a single compromise grants broad system access and expands attack surface.
risk · Context
Vulnerabilities introduced during software development
Inherent weaknesses in programming languages and development environments introduce errors and exploitable vulnerabilities into software products, and software malfunctions cause incorrect outputs, crashes, or security weaknesses.
risk · Context
Hardware and equipment failure
Malfunction or breakdown of storage, processing, communications, sensor, controller, or display equipment (aging, resource depletion, disk errors) disrupting availability or integrity — including intermittent/degraded operation producing incorrect results.
risk · Context
Software and information-system failure
Failure or malfunction of operating-system, networking, or application software (defects, resource depletion, failed releases) causing loss of availability/integrity and impeding mission/business functions — including core banking/payments outages.
risk · Context
Inadequate vulnerability scanning and pre-release testing
Software released without adequate testing, and no regular vulnerability scanning or penetration testing, leaves exploitable defects undiscovered until they manifest — or are exploited — in production.
standard · Direct
SOX / PCAOB (ICFR)
SOX 404 / PCAOB AS 2201 — ICFR control taxonomy
unified · Context
UC-ACCESS-01 — Provision and deprovision accounts through a managed lifecycle
All accounts are created only on a documented, owner-approved request that specifies role-based entitlements and is uniquely attributable to an individual or service. Access is modified on role change and disabled or removed within one business day of termination or loss of authorization, with dormant accounts automatically disabled after a defined period. All provisioning, modification, and deprovisioning events are logged and retained as evidence.
unified · Context
UC-ASSET-12 — Operate scheduled processing, backup, and availability monitoring
Schedule and monitor batch jobs and system processing, investigating and resolving failures through documented incident and problem management. Perform and verify data backups and periodically test recovery capability. Monitor system processing and availability against defined service expectations, with documented follow-up on deviations.
unified · Context
UC-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-CONFIG-02 — Authorize, test, and approve changes before production
Manage changes to applications, databases, infrastructure, configurations, and procedures through a documented process in which changes are requested, analyzed for security and risk impact, authorized, tested, approved, and implemented by appropriate personnel. Require migration to production to be performed by individuals independent of development, and retain records evidencing each step. Define rollback plans and an emergency-change path with retrospective review and approval.
unified · Context
UC-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 · Context
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 · Context
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 · Context
UC-FIN-04 — Authorize transactions with attributable approvals
Require transactions, journal entries, and master-data or configuration changes to be reviewed and approved by authorized personnel in accordance with the delegation-of-authority matrix before they are recorded or executed. Capture approvals in systems under unique authenticated user accounts with tamper-evident audit trails that irrefutably bind each approval to the individual who performed it, so that approval actions cannot be repudiated. Evidence includes the delegation-of-authority matrix, approval workflow configurations, and approval audit trails.
unified · Context
UC-FIN-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 · Context
UC-FIN-06 — Validate completeness and accuracy of system inputs
Implement input controls over data entered into financial systems, including edit and validation checks, required-field and format controls, completeness checks, and rejection or suspense handling of invalid entries, so that inputs are complete, accurate, and valid. Define these controls in documented policies and procedures over system inputs and retest their configuration on change. Evidence includes configuration baselines, validation rules, and rejected-input handling records.
unified · Context
UC-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 · Context
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 · Context
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 · Context
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-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-RISK-06 — Perform periodic enterprise risk assessments
The organization performs an enterprise-wide risk assessment at least annually and upon significant change, identifying and analyzing risks to the achievement of objectives, including cybersecurity, privacy, and financial reporting risks. Assessments follow the documented methodology, address the design of the control environment and evolving threats and technologies, and are approved by management. Assessment reports, methodology references, and approvals are retained as evidence.
unified · Context
UC-RISK-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.
unified · Context
UC-SDLC-01 — Follow a secure development lifecycle with approval gates
Define and follow a documented development lifecycle with security integrated into every phase from requirements through design, build, test, and release, including defined security activities, secure development standards and tooling, and management approval gates. Ensure new systems and significant changes are designed, developed, tested, and approved in accordance with management's specifications before migration to production. Monitor adherence to and performance of the secure development process.
unified · Context
UC-TRAIN-04 — Communicate control responsibilities and reporting channels
Internally communicate each person's internal-control and reporting responsibilities, including objectives, policies, and changes that affect their duties, using quality, timely information. Maintain channels for internal and external parties to raise concerns, including an anonymous whistleblower/ethics hotline, and route what is reported to those responsible for acting on it.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
ITGC Change & Provisioning Testing
Runs ON a control item (a change-management or access-provisioning ITGC). Validates the change and provisioning populations for the period, draws reproducible samples, tests each sampled ticket against the control attributes (approval before migration, segregation of developer and migrator, approval before access, access matches the requested profile), records design and operating conclusions on the control, and raises every exception as an issue.
workflow · Context
Continuous Controls Monitoring (ISCM) Cycle
Run the continuous controls monitoring (ISCM) cycle: pull the current-period control metrics and score them against thresholds, triage degraded and failed controls, update the POA&M, report control health to governance, recalibrate the monitoring strategy, then classify the disposition and prepare, hand off, and archive the cycle package. Each interval runs as one workflow instance attached to the existing Process item that represents the ISCM / continuous-controls-monitoring program (process_type = security_process) — enrich that program record every cycle, never create a duplicate. The monitored control set is the existing Control items (Control.frequency doubles as the monitoring cadence, Control.control_owner as the accountable owner) and the POA&M is the existing Issue register (issue_type = deficiency, source = self_assessment); metric definitions and pass/degraded/fail threshold bands have no native field, so they live in the ISCM strategy document carried on the anchor Process item. The cycle produces the control-health scorecard, the reconciled POA&M, the control-health / security-status report, and the recalibrated ISCM strategy. In scope: the recurring NIST 800-137 monitoring loop — metric collection, threshold comparison, triage, POA&M maintenance, security-status reporting, and monitoring-strategy tuning for the controls under continuous monitoring. Out of scope: formal security control assessment and driving gap remediation to closure, which is owned by the downstream Security Control Assessment & POA&M Remediation workflow that consumes this cycle's handoff package. No upstream workflow feeds this one; it is triggered by the arrival of the monitoring interval.
workflow · Context
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
IT Availability & Resilient Failure Operations
Standing operator workflow for the monthly IT availability and resilient-failure-operations cycle: batch and processing monitoring with incident and problem resolution, backup and restore verification, availability-to-SLA tracking, network capacity and DoS-mitigation posture, fail-secure and alternate-communications readiness, and the mean-time-to-failure replacement queue with verified fail-safe procedures, as a decision-aware flow that escalates an urgent reliability gap immediately and rolls routine findings into a single end-of-cycle corrective-action log. Each monthly instance runs against the EXISTING Control item for this IT-availability and resilient-failure-operations control (frequency: monthly; framework: nist-800-53 + sox; domains: business_continuity_disaster_recovery, network_communications_security, incident_management_response) — it enriches that standing control with the cycle's evidence rather than creating a new record: per-stream evidence attaches as documents on the workflow instance's steps, operational failures and gaps become Issue items linked to that Control, and the named deliverable is the signed monthly control record (the classify-cycle-disposition form plus its disposition summary), backed by the monitoring roll-up, incident-and-problem log, backup-and-restore summary, availability dashboard, capacity and fail-secure verification records, and the corrective-action register. In scope: the in-scope batch jobs and system processing, network services and communications paths, and components tracked for mean-time-to-failure named in the operating brief, measured against their defined availability and processing service expectations; out of scope: application change management, access provisioning, and physical-environment controls, which are operated by their own workflows. This is a standing monthly cycle with no upstream workflow dependency and no downstream handoff — its inputs are the organization's own scheduler and monitoring feeds, backup history, capacity telemetry, and asset/MTTF inventory; its archived record seeds the next monthly instance of the same control.
workflow · Context
Change & Release Management (CAB)
Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.
workflow · Context
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
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
Offboarding & Access Revocation
Runs on the existing personnel item. Revoke a leaver access across every in-scope system within the policy window, evidence each revocation, and approve the revocation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
NIST RMF System Authorization (ATO) Cycle
Runs the seven NIST SP 800-37r2 RMF phases — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — against a single information system to reach and then sustain an authorization-to-operate (ATO) decision. The cycle is anchored on an Audit item created per authorization ("RMF ATO Cycle — <system> <year>", audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the AO decision calendar); the information system itself is enriched as an existing Process item (process_type=security_process). Studio has no System/Asset type, so the RMF-specific facts (FIPS 199 categorization, selected baseline, ATO decision, authorization-termination date) live in the phase documents and on the Audit anchor rather than in dedicated fields. In scope: the defined authorization boundary and its inherited, hybrid, and system-specific controls (existing Control items). Out of scope: enterprise-wide common-control-provider programs and standalone penetration testing, which run as their own engagements and are consumed here only as assessment evidence. Named deliverables: the FIPS 199 categorization memo, the System Security Plan (SSP), the Security Assessment Report (SAR), the Plan of Action & Milestones (POA&M), and the signed ATO letter — assembled into one authorization package for the authorizing official. No upstream workflow feeds this cycle; it originates at Prepare. Downstream it hands off to itself: the Monitor phase's reauthorization triggers re-instantiate this template against the same system, and the Monitor phase's closing export is the authorization record the next cycle's Prepare consumes.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
Control Design Assessment
Runs on the existing control item. Assess whether a control is clearly specified and designed to address its stated risk before deciding what follow-up or testing is appropriate. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control 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
Employee Offboarding
Run on an existing personnel item using an authorized departure record, access inventory and retention instructions. Produce the Employee Departure Package and hand remaining obligations to HR after IT removal evidence and manager handover review.
workflow · Context
Employee Onboarding
Run on an existing personnel item using signed engagement, screening references and an approved role profile. Produce an Onboarding Readiness Package with IT access evidence for HR, the manager and subsequent access reviews.
workflow · Context
System ITGC Operation
Operate and evidence the IT general controls on a system: authentication and password configuration, access provisioning and deprovisioning, the periodic user access review, change management (testing, sign-off, logs), and subservice SOC report reliance.
workflow · Context
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
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
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
Control Responsibility Communications & Ethics Hotline
Control Responsibility Communications & Ethics Hotline as a decision-aware workflow that runs on the existing Control item for control-responsibility communications and the whistleblower/ethics hotline (framework sox + coso-ic, quarterly frequency, control_owner = Ethics & Compliance Officer) — each instance is one quarterly operating cycle of that control, enriching it rather than creating a duplicate. Within the cycle it inventories what changed in control responsibilities this quarter, drafts and distributes tailored communications with tracked acknowledgment, verifies internal and external concern-raising channels including the whistleblower hotline are operating, tests intake-to-routing end to end, and confirms this quarter's real reported matters reached the people responsible for acting on them. The named deliverable is the archived quarterly evidence package — the responsibility-change delta list, the approved tailored communications, the distribution and acknowledgment records, the internal-channel and hotline health summaries, the intake-to-routing test trace, and the real-matter routing review — retained on the anchor Control as durable audit evidence. In scope: this quarter's control-responsibility communications and the operation and intake-to-routing reliability of the internal and external concern-raising channels including the anonymous whistleblower/ethics hotline. Out of scope: investigating or adjudicating the substance of individual reported matters (owned by each case's responsible function) and designing new controls. This cycle consumes no other workflow's handoff package and hands off to no downstream workflow; the quarterly cadence (or an interim trigger such as a reorganization, new policy, control-ownership change, or M&A) is its own trigger.
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
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
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
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
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
Control Interim Testing Record
Runs on the existing control item. Test a defined interim-period population using a documented sampling and attribute plan, then record exceptions and a bounded conclusion. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Period-End Roll-Forward / Rollover Testing
Runs on the existing control item. Bridge an approved interim control test through period end by assessing change, remaining occurrences, incremental evidence, and unresolved exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Control Testing
Runs on an existing SOX-applicable Control under a sox-testing template. SAMPLE reviews history, attributes and reproducible selection; TEST reviews evidence, exceptions and the approved result artifact. Keep fiscal year on Workflow.customFields.sox.fiscalYear and hand the published result to the SOX program.
workflow · Context
Process Walkthrough & Design Assessment
Runs on the existing process item. Perform a SOX process walkthrough, update the ICFR narrative and control mapping, and document design observations for management follow-up. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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.