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. Below is a procedure record you can copy, then two completed ones with example evidence names and the lineage of each artifact.

This page owns the procedure record. For the full policy set, see SOC 2 documentation; for the 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 a SOC 2 criterion to a trigger, an owner, ordered actions, a system of record, evidence, review, an exception path, and a change history. The policy sets the rule; the procedure shows how the rule operates.

“Access is restricted” is a statement. A procedure says who starts the process, who performs each action, what evidence each step creates, and what happens when the normal path fails. The COSO Integrated Framework supplies the control vocabulary, and SOC 2 applies it through the AICPA Trust Services Criteria.

What fields should a SOC 2 procedure record include?

A procedure record needs eleven fields: the risk, the policy objective, the exact criterion, the trigger and cadence, the owner and performers, the ordered steps, the system of record, the evidence output, the reviewer, the exception path, and the change history. With them, a new operator can do the work and a reviewer can reconstruct one completed instance. Copy the table and fill the right-hand column; one procedure can support more than one criterion.

Keep the procedure separate from the evidence: the procedure describes the expected process, and a completed ticket or log shows one instance. For organizing the evidence, 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 says what it represents. For each artifact, record the source system and object, how it was collected, the query or filter, the population and period, the generation time with timezone, an immutable reference, the reviewer, and where it is stored.

The AICPA’s FAQs on software tools in SOC 2 examinations (first issued June 2021, current version dated 31 March 2026) cover tool-produced evidence. Lineage fields make a tool-produced artifact inspectable for the CPA firm. Automation can collect evidence, but it does not decide whether a control is designed well or operated as described; see SOC 2 automation. In the examples below, ticket numbers, report names, and roles are illustrative.

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

An access-provisioning procedure supports CC6.2 when access is authorized before credentials are issued and credentials are removed once access is no longer authorized. It supports CC6.3 when access changes follow the person’s role, with least privilege and segregation of duties in mind. The record must trace a request through the access change and any exception.

The AICPA does not prescribe a ticketing product, identity provider, or approval interval. In our controls library, AC-03 (approval before provisioning) and AC-04 (removal at departure) map to CC6.2, and AC-06 (periodic access review) maps to both criteria. The record below covers AC-03 and AC-04; the review is its own procedure.

The reviewer’s time comparison catches the gap the library flags for AC-03: access granted over chat, with the ticket written afterward.

For the policy above this procedure, see our SOC 2 access control policy template.

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, and implements changes. CC8.1 reads: the entity “authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.”

Write the decision rules for approval and testing into the procedure, scaled to the change’s risk. In our controls library, CM-01 (reviewed pull request), CM-02 (automated checks in the pipeline), CM-03 (deploy only through the pipeline), and CM-04 (emergency path) all map to CC8.1. A solo founder has no second reviewer for CM-01; the library suggests a required test gate and a recorded self-review instead, agreed with your CPA firm.

This is a procedure, not an auditor’s sampling plan. The SOC 2 change management controls guide shows what auditors sample, and SOC 2 Type 2 controls explains how testing differs from documentation.

How should you review and update a control procedure?

Review a procedure when its risk, people, system, or policy changes, and on the cadence you set for that control. Compare the written steps with one recent completed instance and confirm the evidence still carries its lineage fields. Record any mismatch as an exception, never rewrite a past instance, and log the revision in the change history.

If you want help turning this into a readiness plan, see SOC 2 readiness firms.