{"description":"Runs ON a control item (a change-management or access-provisioning ITGC). Validates the change and provisioning populations for the period, draws reproducible samples, reconciles independent deployment and ticket populations in both directions, tests sampled tickets and deployments 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.","edges":[{"id":"e-confirm-design-conclude","source":"confirm-design","target":"conclude"}],"isPublic":true,"itemTypeSlug":"control","metadata":{"capabilities":["audit-testing"],"controlVerbs":{"UC-ACCESS-01":"tests","UC-ACCESS-03":"tests","UC-ACCESS-16":"tests"},"controls":["UC-ACCESS-01","UC-ACCESS-03","UC-ACCESS-16"],"department":"internal-audit","domains":["audit"],"kind":"audit-testing","library":{"aliases":[{"source":"assureplugin","sourceTemplateId":"itgc-change-provisioning-testing"}],"canonicalUrl":"https://evidenceflows.com/workflows/all/?w=itgc-change-provisioning-testing","contentDigest":"sha256:2eb07fc4bfc2c524ac3ae34c6e08fa17bee31e099afa210f9cca502f9476bbc7","prerequisites":{"anchorItemType":{"slug":"control"},"evidenceDestinations":[{"description":"Restricted step documents and native step results retaining source files, review notes and final conclusions.","id":"workpapers"}],"roles":[{"contribution":"expertise","description":"Approves the procedure, scope and precommitted testing or monitoring criteria.","id":"audit-supervisor","nodeIds":["confirm-design"]},{"contribution":"approval","description":"A reviewer other than the preparer; ITGC reviewers must also be independent of control operation.","id":"independent-reviewer","nodeIds":["conclude"]}],"status":"declared"},"provenance":[{"source":"assureplugin/skills/audit-itgc/workflows/itgc-change-provisioning-testing.json","sourceTemplateId":"itgc-change-provisioning-testing"}],"releaseId":"sha256:2eb07fc4bfc2c524ac3ae34c6e08fa17bee31e099afa210f9cca502f9476bbc7","schemaVersion":1,"sourceTemplateId":"workflow-library:itgc-change-provisioning-testing"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"itgc-change-provisioning-testing","source":"coworkcanvas-gallery","standards":["iia-2024","cobit-2019","sox"],"teams":["internal-audit"]},"name":"ITGC Change & Provisioning Testing","nodes":[{"data":{"controls":["UC-ACCESS-01","UC-ACCESS-03","UC-ACCESS-16"],"instructions":"**Objective** — Agree the control-specific attributes, reliable population and sampling plan before testing.\n\n**Inputs** — The existing Control item, period, walkthrough, source ticket extracts, an independently obtained deployment population from production release/migration logs, repository evidence and authorized control-owner context.\n\n**Procedure**\n1. Select the actual control under test: program changes or access provisioning. Collect only its population; companion controls may have separate runs. For changes require authorization before migration, independent developer and migrator, test evidence, and retrospective emergency approval within the stated SLA. Resolve developer, release and migration identity from authoritative repository commits and production logs, linked by immutable commit/build/release identifiers; use requested_by only when its meaning is corroborated. Missing developer or migration identity is undecidable: never record an independence pass from a requester name or blank value. For provisioning require manager approval before access, granted access matching the requested profile and manager identity matching the current Personnel record.\n2. Freeze the source extract with source system, extraction query and parameters, entity, period and timestamp. Reconcile row counts or value to an independent source; inspect query filters and report completeness and accuracy, or cite approved current-period reliance on the same report and parameters. For program changes, obtain production release/migration logs independently of the approved-ticket listing, including emergency, manual and failed/rolled-back activity with the inclusion policy recorded. Reconcile deployment-to-ticket and ticket-to-deployment across the full period: investigate unmatched deployments as possible unauthorized changes and approved tickets with no deployment as timing, cancellation or missing-log cases. Reconcile source-system control totals and query/filter coverage for both populations; the ticket count cannot establish deployment completeness. Profile columns, date boundaries, nulls, numeric ranges and totals. Validate an empty population and record not applicable/no occurrences; draw no sample and make no effectiveness claim.\n3. Use an engagement-approved sampling design. Record the objective/assertion, population, period, sampling unit, risk, method, requested size, sizing basis and expansion policy before selection. Cite the approved policy/version or judgmental rationale for coverage without statistical assurance. Statistical evaluation also requires confidence/sampling risk, tolerable and expected error/deviation, a supported estimator/projection method and treatment of sampling uncertainty. Do not default to the retired population table. Use selection methods only where their assumptions fit the population; record algorithm/version, row order, seed, original population SHA-256, original/excluded/eligible/selected counts and date. For monetary-unit selection retain interval, random start and repeated hit counts; plan separate testing of zero/negative rows. Selection alone does not implement projection or establish confidence.\n4. Precommit an exception policy before seeing results: expand once by a stated increment or stop and evaluate. Preserve the original exception after expansion. Replace only demonstrably out-of-scope, voided or duplicate rows using the same method and seed lineage; missing evidence is an exception. Prefer reperformance and inspection to observation and inquiry; investigate contrary evidence and distinguish an observed failure from an unsupported representation.\n5. Record whether current design is newly assessed or relies on a supported prior conclusion; define scope-change triggers and who independently reviews the test.\n\n**Record in AssureSwarm** — Record attributes, period, method, sample, population evidence and exception policy in the step result; attach extracts and plan. Update actual Control metadata only after resolving field keys.\n\n**Exit criteria** — The audit supervisor provides expertise and approval: the attributes address the selected control objective, population reliance is justified and testing can begin under the approved plan.","label":"Approve ITGC attributes and sampling plan","requiredApprovals":1},"id":"confirm-design"},{"data":{"controls":["UC-ACCESS-01","UC-ACCESS-03","UC-ACCESS-16"],"instructions":"**Objective** — Conclude on design and period operation from every selected ticket and its evidence.\n\n**Inputs** — The approved attributes, reproducible sample, ticket approvals, deployment logs and current HR manager evidence.\n\n**Procedure**\n1. Test the approved ticket and deployment selections against every applicable attribute, record pass, exception, undecidable or not applicable with evidence identifiers and dates, and reconcile tested rows to each selection. Trace deployed build/commit and migration actor back to the authorized release and developer evidence; retain every unmatched deployment and identity gap for evaluation. An unauthorized deployment cannot disappear because it has no ticket. For emergency changes evaluate the approved retrospective SLA; retain failures rather than treating every late approval as compliant.\n2. Precommit an exception policy before seeing results: expand once by a stated increment or stop and evaluate. Preserve the original exception after expansion. Replace only demonstrably out-of-scope, voided or duplicate rows using the same method and seed lineage; missing evidence is an exception. Prefer reperformance and inspection to observation and inquiry; investigate contrary evidence and distinguish an observed failure from an unsupported representation.\n3. Separate design from operating conclusions. Evaluate exception magnitude, likelihood, compensating controls and aggregation; obtain the engagement lead’s severity judgment. Create an Issue for each exception, linked to the Control, with issue_type exception, source internal_audit, owner, root cause and recommendation supported by evidence.\n4. For SOX tracker enrollment, use the canonical sox-control-testing-publication companion. This generic template’s audit-testing classification does not qualify. If an authorized administrator explicitly reclassifies a template through a supported admin path, verify stored metadata.kind = sox-testing and Control.sox_applicable before creating the SOX-hosted run; retain fiscal year in Workflow.customFields.sox.fiscalYear, and publish the approved testing artifact through the native SOX result path. Otherwise retain the period conclusion in the step result. Update control.design_conclusion, interim_result or ye_result and last_tested_fy only where those fields exist and match the result vocabulary; do not treat these updates as SOX publication.\n5. Assemble the population, sample, matrix, review notes, exceptions and approved conclusions as the workpaper; attach to the step and the Control workpaper document field where available.\n\n**Record in AssureSwarm** — Retain the two-way deployment reconciliation, source control totals, ticket/deployment-by-attribute matrix, design and period conclusions, evidence and review notes as results/documents; create native Issue-to-Control links and use native approval records.\n\n**Exit criteria** — An audit reviewer independent of the control operator provides expertise and approval: every selected ticket and deployment has a supported disposition, undecidable identities remain open, no operator approves their own test and follow-up remains visible.","label":"Review ticket testing and conclude","requiredApprovals":1},"id":"conclude"}],"sourceTemplateId":"workflow-library:itgc-change-provisioning-testing"}