SOC 2 Authorization and Approval Procedures Process

Learn how SOC 2 Authorization and Approval Procedures support CC5.2 by enforcing documented approvals for changes and access.

SOC 2 Processes
SOC 2 Authorization and Approval Procedures Process

Overview

Authorization and Approval Procedures is the process for ensuring that system changes, access requests, and operational actions are formally reviewed and approved before execution. It supports SOC 2 CC5.2 by enforcing accountability and preventing unauthorized activities through documented approvals.

Step-by-Step Process

  1. Define approval requirements

    The Engineering Lead documents which actions require prior authorization, such as code changes, access grants, and production deployments. This definition is reviewed annually and communicated to the engineering team. The output is a written approval matrix or policy section.

    Role: Engineering Lead

  2. Submit request for authorization

    The requester creates a formal request describing the change or access needed, business justification, and scope. Requests are submitted through the designated tool before any work begins. The output is a logged request with a timestamp.

    Role: Engineer

  3. Review request details

    An authorized approver reviews the request for completeness, risk, and alignment with documented requirements. Any missing information is requested before approval is granted. The output is a review decision recorded in the tool.

    Role: Engineering Lead

  4. Approve or reject request

    The approver formally approves or rejects the request within the system using their assigned credentials. Approval must occur before implementation and include an electronic record of the approver and date. The output is an approval or rejection log.

    Role: Engineering Lead

  5. Implement approved action

    The requester performs the approved action strictly within the authorized scope. Any deviations require a new authorization request. The output is a completed change or access update linked to the approval record.

    Role: Engineer

  6. Retain approval evidence

    Approval records and related artifacts are retained for audit purposes according to the retention policy. The Engineering Lead ensures records are accessible and complete. The output is an auditable approval history.

    Role: Engineering Lead

What You Need Before Starting

  • Documented approval matrix or authorization policy
  • Access to GitHub, Jira, or ServiceNow
  • User accounts with approver permissions
  • Change, access, or deployment request details

Evidence Your Auditor Expects

  • GitHub pull request showing approver review and merge approval with date and time
  • Jira issue with approval status, approver name, and timestamp
  • ServiceNow request record with approval workflow history and approval date
  • Exported approval log or screenshot showing approved requests during the audit period

How This Looks In Your Tools

GitHub

Navigate to the repository and select the relevant pull request from the Pull requests tab. Review the Files changed and Conversation tabs to assess the request details.

As an approver, select Review changes, choose Approve, and submit the review. Ensure branch protection rules are enabled by going to Settings > Branches > Branch protection rules and requiring at least one approving review before merge.

Jira

Open the Jira project and select the issue type used for changes or access requests. Review the Description, Attachments, and custom approval fields.

Update the Approval field or transition the issue to an Approved status using the workflow buttons. Confirm the approver name and timestamp are visible in the issue History tab.

ServiceNow

Go to All > Requests > Open Requests and select the relevant request record. Review the request details and associated risk or justification fields.

Use the Approve or Reject buttons in the Approval section. Verify the approval is logged by checking the Activity > Approvals history with date and approver name.

Common Audit Findings

Changes implemented without documented approval
This occurs when teams bypass formal request workflows under time pressure. Prevent this by enforcing tool-based approvals and enabling technical controls like branch protection or mandatory approval states.
Approvals performed after implementation
Post-implementation approvals weaken control effectiveness and are often flagged by auditors. Require approvals before status transitions or merges to prevent retroactive authorization.
Unauthorized users approving requests
This happens when approver roles are not clearly restricted. Limit approval permissions to designated roles and review approver access quarterly.
Incomplete approval records
Missing timestamps or approver names reduce audit reliability. Configure tools to require mandatory approval fields and retain system-generated logs.

Related Processes

Key Roles

Engineering LeadEngineer