{"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, 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.","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://workflow-library.com/all/?w=itgc-change-provisioning-testing","contentDigest":"sha256:568bf412eaf4229147a7556e111d5bda5641422d9748cdb97eb66cf112123da4","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:568bf412eaf4229147a7556e111d5bda5641422d9748cdb97eb66cf112123da4","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 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 identity from authoritative ticket or repository evidence; use requested_by only when its meaning is corroborated. 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. 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 the engagement-approved sampling methodology. The source method uses this nonstatistical baseline for occurrence populations: at most 50 items, round up 10% with a floor of 5 capped at the population; 51–250 items, round up 15%; above 250, 25/40/60 for low/moderate/high risk. Increase for prior deficiencies, changed controls, sole safeguards, elevated risk or external reliance. This baseline does not establish statistical assurance; document the assurance objective, materiality, tolerable error and any statistical design separately. Choose random for homogeneous populations, systematic for temporal coverage, monetary-unit sampling for positive monetary exposure, and documented targeted strata as a supplement. Record the algorithm/version, input row order, seed, population SHA-256, size and date so another tester can reproduce the draw.\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 each selected ticket against every applicable attribute, record pass, exception or not applicable with evidence identifiers and dates, and reconcile tested rows to the selection. 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 ticket-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 has a supported disposition, 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"}