SOC 1
80 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
SOC1-1 — Logical access — controls provide reasonable assurance that logical access to applications, data, and infrastructure is restricted to authorized and appropriate users (authentication, authorization, provisioning/deprovisioning, periodic access review, privileged access).
Logical access — controls provide reasonable assurance that logical access to applications, data, and infrastructure is restricted to authorized and appropriate users (authentication, authorization, provisioning/deprovisioning, periodic access review, privileged access).
control · Direct
SOC1-10 — Physical security and environmental controls — controls provide reasonable assurance that physical access to facilities and data centers is restricted and that environmental protections safeguard systems.
Physical security and environmental controls — controls provide reasonable assurance that physical access to facilities and data centers is restricted and that environmental protections safeguard systems.
control · Direct
SOC1-11 — System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
control · Direct
SOC1-12 — Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
control · Direct
SOC1-2 — Change management — controls provide reasonable assurance that changes to applications and infrastructure are authorized, tested, approved, and migrated to production appropriately.
Change management — controls provide reasonable assurance that changes to applications and infrastructure are authorized, tested, approved, and migrated to production appropriately.
control · Direct
SOC1-3 — Program development / SDLC — controls provide reasonable assurance that new systems and applications are developed, tested, approved, and implemented in accordance with management's intent.
Program development / SDLC — controls provide reasonable assurance that new systems and applications are developed, tested, approved, and implemented in accordance with management's intent.
control · Direct
SOC1-4 — Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
control · Direct
SOC1-5 — Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
control · Direct
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 · Direct
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 · Direct
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 · Direct
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.
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
User error and mishandling of sensitive information
Authorized users make mistakes — incorrect data entry, misconfiguration, improper procedures, incorrect privilege settings, or spilling/mishandling sensitive information — causing harm to information assets without malicious intent.
risk · Context
IT resilience failure — unplanned outage, data loss, slow recovery
Critical technology infrastructure or applications experience unplanned outages, data loss, or prolonged recovery times — including failure of DR systems to activate — disrupting operations and harming stakeholders.
risk · Context
Absent or untested business continuity / disaster recovery plan
No BCP/DR plan, or plans that exist but have never been exercised end-to-end, so a natural disaster, pandemic, civil unrest, or infrastructure failure disables critical processes with no tested recovery path.
risk · Context
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
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
Missing or insufficient logging and audit trails
Absence of logging/audit trails means unauthorized activity cannot be detected, investigated, or attributed, and adversary actions (obfuscation of intrusion detection, tampering with logs) go unnoticed.
risk · Context
No security monitoring or supervision of privileged activity
Absence of monitoring mechanisms and supervision of personnel actions (especially privileged users) allows undetected misuse, and no process exists to supervise and escalate detected security breaches.
risk · Context
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
Physical and cyber-physical attacks on facilities and infrastructure
Adversary conducts physical attacks on facilities (arson) or supporting infrastructure (cuts power/water), or cyber-physical attacks (remotely altering HVAC), damaging systems and supporting utilities.
risk · Context
Environmental degradation of equipment (dust, humidity, temperature, EMI)
Equipment sited without environmental controls suffers from dust, corrosion, freezing, humidity, voltage or temperature variation, and electromagnetic/thermal radiation or EMP, causing malfunction or failure.
risk · Context
Inadequate protection against fire, flood and physical hazards
Absence of fire suppression, smoke detection, flood barriers, or drainage in facilities housing information assets, and poor cabling infrastructure susceptible to damage, tapping, or accidental disconnection.
risk · Context
Inadequate physical protection and access controls
Buildings and sensitive areas lacking perimeter security, key-card/lock/mantrap controls, or supervision of visitors and cleaning/outside staff allow unauthorized physical access to equipment and media — including tailgating past physical checks.
risk · Context
Theft of equipment, media or unattended devices
Physical stealing of storage media, printouts, or computing/network equipment (including unattended laptops outside the perimeter), potentially exposing stored data. Unprotected storage locations increase exposure.
risk · Context
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
Loss of essential services (power, HVAC, telecoms)
Interruption of power supply, air-conditioning/water utilities, or telecommunications — from unstable grids, single power feeds, UPS/generator failure, or carrier/fiber outages — stops operations or harms equipment and personnel.
risk · Context
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
Critical vendor failure, insolvency or concentration
A key supplier, SaaS provider, or outsourced partner becomes insolvent, exits the market, or suffers a prolonged outage; sole-source and shared-tier concentration (multiple tier-1 vendors on a common tier-2) creates hidden single points of failure with no backup.
risk · Context
Third-party compliance failure creating vicarious liability
A vendor, subcontractor, or channel partner violates labor, environmental, anti-bribery (FCPA/UKBA), or data-protection rules, exposing the company to liability and reputational harm; fourth-party/N-tier dependencies are opaque.
risk · Context
Vendor/outsourcing service non-performance and disputes
Outsourced processing, IT, payroll/HR, print/mail, or sub-custodian providers fail to meet service levels, deliver defective software, make incorrect payments, or breach contractual deliverables, causing processing errors, outages, and loss.
risk · Context
Weak supplier security requirements and monitoring
Because supplier contracts omit security requirements and SLAs and third-party service delivery is not monitored, processors and sub-processors operate without equivalent, audited obligations, so third-party weaknesses and breaches propagate into the organization undetected.
risk · Context
Inadequate vulnerability scanning and pre-release testing
Software released without adequate testing, and no regular vulnerability scanning or penetration testing, leaves exploitable defects undiscovered until they manifest — or are exploited — in production.
standard · Direct
SOC 1
SOC 1 (SSAE 18 / ISAE 3402) — service-org ICFR control objectives
unified · Context
UC-ACCESS-01 — Provision and deprovision accounts through a managed lifecycle
All accounts are created only on a documented, owner-approved request that specifies role-based entitlements and is uniquely attributable to an individual or service. Access is modified on role change and disabled or removed within one business day of termination or loss of authorization, with dormant accounts automatically disabled after a defined period. All provisioning, modification, and deprovisioning events are logged and retained as evidence.
unified · Context
UC-ACCESS-16 — Authorize, test, and approve changes and development
Changes to applications and infrastructure, and new system development, follow a documented lifecycle: authorized request, risk-assessed design, testing in non-production environments, documented approval, and controlled migration to production by personnel independent of development. Emergency changes are ratified retrospectively, and evidence of each gate is retained.
unified · Context
UC-ACCESS-17 — Execute, monitor, and recover production processing
Production batch jobs and scheduled processing are defined, authorized, and monitored, with failures and exceptions logged, tracked, and resolved in a timely manner. Data is backed up on a defined schedule with protected, retained copies, and restoration is periodically tested to confirm recoverability within objectives.
unified · Context
UC-ACCESS-18 — Log and monitor system activity, capacity, and incidents
Systems generate log records that are protected and made available for continuous monitoring. Performance, capacity, and security events are monitored against thresholds, with alerts triaged and incidents identified and resolved through a tracked process. Resource use is projected and tuned to meet current and future capacity requirements.
unified · Context
UC-ACCESS-19 — Restrict physical access and maintain environmental safeguards
Physical access to facilities, data centers, and protected assets is authorized, badged, logged, monitored, and revoked on separation, commensurate with risk. Environmental protections including power conditioning and backup, fire detection and suppression, and temperature and humidity control safeguard systems, and physical access and environmental events are reviewed.
unified · Context
UC-ACCESS-20 — Ensure complete, accurate, and authorized data processing
Transactions and data entering the system are validated for completeness, accuracy, and authorization through edit checks, batch totals, and exception queues. Interfaces and transmissions between systems are controlled with reconciliation, error handling, and timeliness checks, and processing applies complete and accurate logic in the proper period. Outputs and reports are validated and distributed only to authorized recipients.
unified · Context
UC-ACCESS-21 — Manage subservice organizations supporting the system
Subservice organizations relevant to user entities' control objectives are identified, contractually bound to security and processing commitments, and monitored through review of their independent assurance reports, complementary user-entity controls, and performance. Identified issues are tracked to resolution.
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
Vendor SOC 1/SOC 2 Report Review & CUEC Mapping
Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.
workflow · Context
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
Facility Access Administration & Monitoring
Standing monthly operator workflow anchored to the existing **Facility Access Administration** Process item (process_type: security_process), with the operated Control items UC-PHYS-01, UC-PHYS-02, and UC-ACCESS-19 (control_category: physical, frequency: monthly) linked to it; each cycle runs as a fresh workflow instance and its reconciliation packages, decision forms, and Issue items attach to that instance. It covers credential authorization, entry control and visitor logging, key/badge custody and revocation — plus the monthly surveillance, access-log, and environmental-safeguards review with facilities, including the data-center and protected-asset access confirmation. In scope: authorization, issuance, and periodic re-justification of physical credentials; entry-control and visitor-escort enforcement; key/combination/badge custody, rotation, and revocation; and the monthly surveillance, access-log, visitor-record, and environmental-safeguards review across all facilities, perimeters, and secure areas including the data center and other protected-asset locations. Out of scope: logical/system access provisioning and full incident-response investigation — a confirmed intrusion or data-center compromise is handed off to the incident-response process. No upstream workflow feeds this capability; it runs on its own monthly cadence and on personnel-change and reported-anomaly triggers, and terminates at close-and-archive (the run itself is the retained audit trail — no other downstream workflow consumes the cycle package). Control references: NIST 800-53 PE-2/PE-3/PE-6/PE-8, ISO 27001 A.7.1–A.7.4/A.7.6.
workflow · Context
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
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
Job Scheduling & Batch Monitoring
Runs on the existing system item. Review scheduled job execution for a system over a period, evidencing failure detection, escalation, and resolution. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Data Conversion & Migration
Runs on the existing system item. Convert data into a target system with evidenced completeness and accuracy reconciliation between source and target. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
End-User Computing Inventory & Validation
Runs on the existing system item. Inventory the spreadsheets and end-user tools feeding reporting for a system, and test their access, change, and integrity controls. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
ISO 27001 Stage 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 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
Employee Offboarding
Run on an existing personnel item using an authorized departure record, access inventory and retention instructions. Produce the Employee Departure Package and hand remaining obligations to HR after IT removal evidence and manager handover review.
workflow · Context
Employee Onboarding
Run on an existing personnel item using signed engagement, screening references and an approved role profile. Produce an Onboarding Readiness Package with IT access evidence for HR, the manager and subsequent access reviews.
workflow · Context
GCP Physical and Environmental Subservice Reliance
Evaluate GCP assurance-report scope, physical and environmental controls, exceptions and user responsibilities; record a bounded reliance decision rather than claiming to operate provider facilities. This customer-side review relies on relevant independent reports, disclosed provider information and customer implementation evidence. It does not operate or certify GCP facility access or environmental safeguards. Preserve each report's permitted-use restrictions.
workflow · Context
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
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
Subservice Organization & Third-Party Personnel Oversight
Subservice Organization & Third-Party Personnel Oversight as a checkpoint graph. Anchor: each run enriches the existing subservice-organization **Vendor** register entry for one provider - the workflow instance and every step document attach to it, and it is never recreated (initial vendor selection and onboarding due diligence are out of scope). In scope: the subservice organizations and third-party suppliers whose services support user-entity control objectives or whose personnel access the organization's systems or data - reconciling and enriching their Vendor register entries, verifying subservice and personnel-security contract terms, reviewing assurance (SOC) reports and mapping complementary user-entity controls (CUECs) to internal Control items, routing exceptions to tracked Issue items, collecting third-party personnel-compliance evidence, monitoring vendor performance, and running the quarterly issue follow-up through to closure. Out of scope: initial vendor selection and onboarding due diligence, and the organization's own internal personnel controls. Upstream: no workflow feeds it - it is built from the existing Vendor register, the prior cycle's archived vendor file, open Issue items, and the internal Control inventory, plus contracts, SOC reports, and performance data uploaded as evidence. Downstream: self-contained - no single workflow consumes its output; the archived, auditor-ready vendor file is the durable evidence record. It runs on the annual per-vendor cycle with quarterly issue follow-up.
workflow · Context
SOC Report, Subservice & CUEC Review
Runs on the existing system item. Evaluate a service-organization report, subservice coverage, exceptions, and complementary user-entity controls for a governed reliance decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.