Introduction
Corrective and preventive action (CAPA) evidence shows an auditor that when a control failed, an incident happened, or an audit finding was raised, your team found the cause, fixed it, and checked that the fix worked. This guide covers which records to keep for each step of a CAPA workflow and how those records connect to SOC 2 testing.
For the definition of the term, see What Is CAPA?. For handling audit findings and exceptions more broadly, see Exception Management and Audit Findings Remediation.
Where CAPA Fits in SOC 2
SOC 2 does not use the term CAPA. The AICPA Trust Services Criteria include CC4.2, which addresses evaluating and communicating internal control deficiencies in a timely manner to the parties responsible for corrective action. Incident response criteria in CC7 also cover remediating and recovering from security incidents.
A documented CAPA process is one common way teams show they meet those expectations. ISO 27001 is more direct: it includes a requirement for nonconformity and corrective action. If you map controls across both frameworks, see Mapping Controls Across SOC 2 and ISO 27001.
What Usually Triggers a CAPA
Teams commonly open a corrective action record for:
- A control failure found by internal monitoring
- An exception noted by an auditor in a prior report
- A security incident or near miss
- A finding from an internal audit or risk assessment
- A penetration test or vulnerability finding that points to a process gap
Define your triggers in policy so it is clear when a CAPA is required and when a normal ticket is enough.
Evidence for Each Step
Step 1: Record the issue
Keep a dated record that describes what happened, which control or system was affected, how it was found, and who reported it. A ticket in your existing tracker works well because it has a timestamp and history.
Step 2: Assign an owner and due date
Each CAPA should have a named control owner or responsible person and a target date based on severity. Auditors commonly look for this as evidence that deficiencies were communicated to the people responsible for fixing them.
Step 3: Analyze the root cause
Document why the issue happened, not just what happened. A short written analysis is enough for most issues. The goal is to show that the fix addresses the cause rather than only the symptom.
Step 4: Take corrective action
Link the CAPA to the changes that fixed it, such as configuration updates, pull requests, policy revisions, or training. Those linked records are often stronger evidence than a summary note. If the fix is a production change, it should follow your normal change management process.
Step 5: Take preventive action
Record what you changed to stop the same issue from happening again, such as a new automated check, an updated procedure, or an added review step.
Step 6: Verify effectiveness
Before closing, check that the fix worked and record how you checked. Examples include rerunning the control, reviewing a later sample, or confirming an alert now fires as expected. Closing a CAPA without an effectiveness check is a common gap.
Step 7: Close with approval
Record who approved closure and when. Keep the full history so an auditor can follow the record from opening to closure.
Example CAPA Record Fields
| Field | Why it matters |
|---|---|
| ID and open date | Shows when the issue was recorded |
| Source and trigger | Links the CAPA to the finding, incident, or control |
| Description | States what happened |
| Owner and due date | Shows accountability and timeliness |
| Root cause | Shows the fix targets the cause |
| Corrective and preventive actions | Links to the changes made |
| Effectiveness check | Shows the fix worked |
| Closure approval and date | Shows the record was reviewed before closing |
This is an example structure. Use the fields your policy and auditor expect.
How Auditors Commonly Test CAPA
Practices vary by firm, but auditors commonly:
- Request a population of corrective actions opened during the audit period
- Select a sample and trace each item from trigger to closure
- Check that owners and due dates were assigned and met, or that delays were explained
- Look for evidence of the effectiveness check
- Compare prior year exceptions to the current year to see whether issues repeated
Ask your auditor what they plan to test rather than assuming.
Common Gaps
- CAPAs closed with no record of the actual fix
- No root cause recorded, so the same issue repeats
- Overdue items with no explanation or updated date
- Effectiveness checks skipped or undocumented
- Corrective work done in chat with no lasting record
- Prior year exceptions with no linked corrective action
A Practical Preparation Checklist
- Define CAPA triggers, severity levels, and target timelines in policy
- Use one tracker with consistent fields for every CAPA
- Link each CAPA to its source finding and to the changes that fixed it
- Require a root cause and an effectiveness check before closure
- Review open CAPAs on a regular schedule and record the review
- Export the CAPA log for the audit period before fieldwork starts
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
When corrective work happens in tickets and pull requests, that history can make it easier to show the path from finding to fix. AuditFlo.co does not perform root cause analysis for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Good CAPA evidence tells a simple story: what went wrong, who owned it, why it happened, what changed, and how you know the fix worked. Keep that story in dated, linked records and it is much easier for an auditor to follow.
FAQ
Does SOC 2 require a formal CAPA process?
No. SOC 2 does not name CAPA. It expects deficiencies to be evaluated and communicated to the people responsible for corrective action. A CAPA process is a common way to show that.
What is the difference between corrective and preventive action?
Corrective action fixes the issue that happened. Preventive action changes your process so the same issue is less likely to happen again.
How is CAPA different from remediation?
Remediation usually means fixing a specific issue. CAPA adds root cause analysis, preventive steps, and an effectiveness check around that fix.
Do we need a CAPA for every exception?
It depends on your policy and the severity of the exception. Define the threshold in writing and apply it consistently.
Can a CAPA stay open past the audit period?
Yes, if the work is still in progress. Keep the record current with status, owner, and an updated target date, and be ready to explain the timeline.