SOC 2 Internal Control Procedure: Template and Examples

A SOC 2 internal control procedure records how a named person responds to a defined risk, what they do, where the work is recorded, and what evidence proves it happened. Use the template below to turn a policy into instructions another employee can execute and a CPA firm can trace.

This page owns the procedure record itself: risk, steps, evidence lineage, review, exceptions, and updates. For the broader catalog of controls, use the SOC 2 controls list; for gap analysis, use the SOC 2 readiness assessment.

What is an internal control procedure in SOC 2?

An internal control procedure is the operating record behind a control: it links a risk and SOC 2 criterion to a trigger, owner, ordered actions, system of record, evidence, review, exception path, and change history. A policy sets the rule; the procedure shows how the rule operates.

The COSO Internal Control—Integrated Framework organizes internal control around five components: control environment, risk assessment, control activities, information and communication, and monitoring. SOC 2 applies that discipline to a service organization through the AICPA Trust Services Criteria.

For a procedure, the useful unit is not a broad statement such as “access is restricted.” It is a reproducible record: who starts the process, who performs each action, the evidence created at each step, and what happens when the process cannot follow its normal path.

What fields should a SOC 2 procedure record include?

A complete SOC 2 procedure record identifies the risk, exact criterion, trigger, accountable people, steps, source system, evidence, review, exceptions, and version history. Those fields let a new operator perform the work and let a reviewer reconstruct one completed instance without relying on memory.

• Risk: The specific unwanted event the procedure addresses, such as unauthorized production access or an untested production change.
• Policy and control objective: The policy requirement and the result the procedure must achieve. Do not restate a whole policy; name the relevant requirement.
• Exact SOC 2 criterion: The applicable AICPA criterion reference, such as CC6.2, CC6.3, or CC8.1. One procedure can support more than one criterion.
• Trigger and event/cadence: The event that starts the work and, if it is recurring, the cadence chosen for this control. State why that timing fits the risk; do not copy a universal schedule.
• Owner and performers: One accountable owner, plus each role that requests, approves, performs, or reviews the work.
• Ordered steps: Numbered actions in the order an operator performs them, including the decision points that change the path.
• System of record: The system that records the action, such as an approved request queue, source-control repository, identity provider, or deployment log.
• Evidence output: The records produced by a completed instance: request, approval, log, report, test result, review decision, or other source-native artifact.
• Reviewer: The role that checks the result, what the reviewer verifies, and where the review decision is recorded.
• Exception handling: How the team records an emergency, failed step, missing evidence, or approved deviation; who accepts the risk; and how follow-up is closed.
• Change history: Procedure version, change date, editor, reason for the change, approval, and the effective date.

Keep the procedure separate from the evidence it describes. The procedure explains the expected process; a completed ticket, export, or log shows one instance. For an evidence repository structure and request preparation, use the SOC 2 evidence request list.

What evidence-lineage fields are needed for tool-generated evidence?

Tool-generated evidence needs lineage because an export alone rarely explains what it represents. Record the source system, query or integration, population, time range, generation time, reviewer, and storage location so a reviewer can reproduce and interpret the artifact. The AICPA’s March 2026 software-tools FAQ addresses completeness, accuracy, auditor responsibilities, and independence; the fields below make that context inspectable.

Add these fields whenever a procedure relies on a connected evidence pull, scheduled report, API export, or generated test result:

• Source system and object: Identity provider user directory; production repository pull request; CI/CD deployment run.
• Collection method: Native report, saved query, API integration, or manually initiated export.
• Query, filter, or configuration: The saved report name, query identifier, included groups, repository, environment, or rule version used to produce the output.
• Population and period: Which users, changes, or configurations were included, and the event window or as-of timestamp.
• Generation timestamp and timezone: When the evidence was created, including the timezone used by the source system.
• Immutable reference: Source URL, report identifier, run identifier, commit SHA, ticket number, or file checksum when the system provides one.
• Reviewer and disposition: Who checked completeness and accuracy, when they did so, and whether the evidence passed, failed, or needs follow-up.
• Retention location: The controlled folder, evidence platform record, or other repository where the artifact and its context are stored.

Automation can collect or surface evidence, but it does not decide whether a control is properly designed or operating as described. Preserve the source-native record and document the human review the procedure requires. For a decision framework on automation boundaries, see SOC 2 automation.

How does an access-provisioning procedure support CC6.2 and CC6.3?

An access-provisioning procedure supports CC6.2 and CC6.3 when it authorizes users before credentials are issued, then grants, changes, or removes access according to the person’s role and system design. The procedure must leave a trace from the request through the access change and any exception.

The AICPA criteria do not prescribe one ticketing product, identity provider, or approval interval. Configure the record around the systems and roles your organization actually uses.

• Risk: A person receives access they are not authorized to have, or retains access after a role change or departure.
• Policy and criterion: Access-control policy; CC6.2 and CC6.3.
• Trigger and owner: An approved hire, transfer, role change, or termination request starts the procedure. The designated access-control owner is accountable for the procedure.
• Ordered steps:
  1. The authorized requester identifies the person, role, requested systems, and business need in the system of record.
  2. The designated approver confirms the request matches the role and scope.
  3. The administrator or approved workflow creates, changes, or removes access.
  4. The performer records the completed action and any access boundary applied.
  5. The reviewer checks that the request, approval, and resulting access agree.
• System of record: The approved request record linked to the identity system or application administration record.
• Evidence output: Request and approval, identity or application audit event, assigned group or role, completion record, and reviewer decision.
• Event/cadence: Event-driven for hires, role changes, and departures. If a separate access review is part of the control design, record its selected cadence and rationale in that review procedure.
• Exception: Emergency access, unavailable approver, or incomplete identity data is logged with the reason, temporary scope, risk acceptance where required, and a follow-up action.
• Change history: The procedure records changes to role definitions, approval paths, connected systems, or review logic before the revised procedure takes effect.

This example does not replace the complete set of logical-access controls. Use the SOC 2 Trust Services Criteria guide for scope and the SOC 2 controls list for the wider control context.

How does a change-management procedure support CC8.1?

A change-management procedure supports CC8.1 when it records how the organization authorizes, designs, tests, approves, documents, and implements changes that affect the system. A strong record connects the request, engineering work, test result, release decision, and deployed change without claiming that every change follows one identical path.

CC8.1 calls for managing changes to infrastructure, data, software, and procedures. The appropriate approval and testing path depends on the change’s risk and your documented system design; state those decision rules in the procedure rather than applying a blanket SLA.

• Risk: A production change introduces an error, security weakness, or unavailable service because it was not evaluated, tested, or authorized.
• Policy and criterion: Change-management policy; CC8.1.
• Trigger and owner: A proposed change to in-scope code, infrastructure, configuration, data, or operating procedure starts the record. The change-control owner is accountable for the process.
• Ordered steps:
  1. Record the proposed change, affected system, purpose, risk, and rollback or recovery approach.
  2. Classify the change under the organization’s documented decision rules.
  3. Obtain the required review or approval before implementation.
  4. Record the required test or validation results.
  5. Implement through the approved release path.
  6. Link the deployment or configuration record to the request and document the outcome.
  7. Escalate failed validation, emergency work, or an incomplete record through the exception path.
• System of record: The change record linked to source control, infrastructure configuration, test output, and deployment records where applicable.
• Evidence output: Change request, reviewer approval, pull request or configuration change, test result, deployment or release record, and any post-change review decision.
• Event/cadence: Event-driven for each in-scope change. A periodic review applies only if your control design calls for one and should state its purpose and population.
• Exception: An emergency or retrospective change records the reason, approver, scope, implementation record, and required follow-up review.
• Change history: Procedure revisions record changes to classification rules, approval requirements, testing expectations, release paths, or connected systems.

The example defines a procedure, not an auditor’s sampling plan. For the distinction between a documented process and testing its operation across an observation period, see SOC 2 Type 2 controls.

How should you review and update a control procedure?

Review a control procedure when its risk, people, system boundary, policy, source system, or evidence path changes, and on the cadence your organization has chosen for that control. The review should confirm that the written steps still match the work people perform and that the listed evidence can still be produced.

Use a short review record:

1. Compare the documented trigger, owner, steps, and system of record with a recent completed instance.
2. Confirm that the evidence output contains the lineage fields needed to identify its source, population, period, and reviewer.
3. Record any mismatch as an exception or remediation item; do not silently rewrite history to make a prior instance appear compliant.
4. Update the procedure through its documented change path, then record the version, approver, effective date, and any retraining or communication needed.

A good procedure gives the team a stable way to perform one control. It does not replace readiness work, a controls inventory, or an auditor’s test plan. Those adjacent tasks have different records and different owners.