.svg)
TL;DR: SOC 2 compliance requires a formal, trackable process for all security-relevant activities. Under the Trust Services Criteria, this means using a ticketing system with clearly defined Service Level Agreements (SLAs) for vulnerability patching (CC7.1), security incidents, and other critical tasks. Auditors verify adherence to these SLAs. Severity-based SLA tiers (Critical: 24-48 hours, Medium: 14 days, Low: 60-90 days) provide the structure. GRC platforms can automate evidence collection, connect to ticketing systems, and monitor SLA compliance, simplifying the audit process significantly.
Operationalizing SOC 2: Formal Tracking and SLAs
Achieving and maintaining SOC 2 compliance isn't just about implementing controls. It's about proving they work consistently. The final phase of operationalizing SOC 2 controls involves how you respond to security events, whether they are system vulnerabilities, security incidents, or necessary system changes. This capability is primarily achieved through a formal, trackable process, usually managed via a ticketing system.
For auditors, comprehensive evidence is non-negotiable. They require proof that all security-relevant activities are formally tracked, assigned, and resolved. The SOC 2 Trust Services Criteria, particularly criteria like CC7.1 (Vulnerability Management), demand that issues are addressed in a timely manner as defined by your documented SLAs. Without a clear, auditable trail, proving control effectiveness becomes a significant hurdle.
The Core Principle
SOC 2 auditors don't just ask do you patch vulnerabilities? They ask show me the ticket, the SLA, who owned it, and whether it was resolved on time. The ticketing system is the evidence layer that makes your security program auditable.
What Demands Formal Tracking
A ticketing system is the primary mechanism for demonstrating accountability and control effectiveness. It provides the audit trail: the date an issue was identified, its assigned severity, who was responsible, the time taken for resolution, and the final resolution steps.
While tracking any system change is good practice, certain activities are critical for SOC 2 and demand formal tracking with associated SLAs:
Consider how a customer's access request, a new feature deployment, or a database patch directly impacts security posture and SOC 2 readiness. Each of these should flow through a formal tracking mechanism.
Defining and Enforcing Service Level Agreements (SLAs)
The concept of timely remediation, a cornerstone of SOC 2, is explicitly defined by formally documented SLAs. An auditor will test a sample of tickets to ensure the resolution time met the stated SLA. These SLAs must be formally documented in policies such as the Incident Response Policy or Vulnerability Management Policy.
SLAs should be applied based on the severity of the issue, reflecting its potential impact on security, confidentiality, availability, or processing integrity.
| Severity | SLA Window | Typical Scenarios |
| Critical / High | 24 hours to 7 days | Zero-day exploits, confirmed security incidents, unauthorized data exfiltration |
| Medium | 14 to 30 days | Vulnerabilities not publicly exposed, non-critical system misconfigurations |
| Low | 60 to 90 days | Minor hardening recommendations, informational scan findings |
When an SLA Is Missed
Document the justification (e.g., required a third-party patch that was delayed) and any compensating controls implemented during the delay. This demonstrates awareness and active risk mitigation, which is what auditors are looking for.
Practical Application: Vulnerability Patching SLAs (CC7.1)
Vulnerability patching is a high-focus area for SOC 2 auditors, particularly for publicly exposed systems or customer-facing applications. Under Trust Services Criteria CC7.1, controls must be in place to manage vulnerabilities and implement corrective actions.
Vulnerability tickets can originate from various sources: automated SAST/DAST scans during the CI/CD pipeline, daily threat intelligence monitoring, or penetration testing results. Regardless of the source, the organization must have an explicit policy stating the SLA for patching vulnerabilities based on their severity, often defined by systems like CVSS scoring.
Example Scenario
A SaaS company runs a publicly accessible API. A penetration test identifies a critical SQL injection vulnerability. Per the Vulnerability Management Policy, critical vulnerabilities must be remediated within 48 hours. The team creates a ticket, assigns it to the development lead, and tracks progress. The auditor later reviews this ticket to confirm it was resolved within the 48-hour window, providing direct evidence of CC7.1 adherence.
Practical Application: Incident Response SLAs
When a security incident occurs, response time is paramount, directly impacting the Availability and Confidentiality criteria of SOC 2. Policies must clearly define what constitutes a security incident versus a standard operational issue to ensure appropriate escalation and response.
An SLA must be set not just for resolution, but also for detection, triage, and initial response. This demonstrates the ability to limit the damage and duration of a security event.
The auditor examines the incident ticket's timeline, confirming that the team met the defined SLAs for detection, triage, and initial response. A single missed SLA with no documented justification raises more questions than any technical finding.
Streamlining with GRC Platforms
While standalone ticketing systems like Jira, ServiceNow, or Linear work, integrating them with a Governance, Risk, and Compliance (GRC) platform significantly simplifies evidence collection and ongoing compliance. Without integration, auditors manually request comprehensive lists of all security-related tickets, their SLAs, and their resolution times, creating a labor-intensive process.
Platforms such as Secureframe, Vanta, Drata, or Scrut connect directly to task management systems and automatically apply SOC 2 principles to tickets.
Without GRC Integration
- Auditor manually requests ticket exports
- Team manually correlates tickets to controls
- SLA compliance calculated by hand from spreadsheets
- Evidence gaps discovered during audit, not before
With GRC Integration
- Integration & Filtering: Labels like
SOC2-VULNorSECURITY-INCIDENTautomatically pull relevant tickets into the compliance workspace - SLA Monitoring: Severity-based SLAs configured in the platform, with real-time tracking against targets
- Evidence Provisioning: Comprehensive SLA compliance reports generated automatically at audit time
- Continuous Compliance: Alerts for missed SLAs or emerging compliance gaps before they become audit findings
Proactive Security Governance
Effective ticketing and SLA management are not compliance checkboxes. They are fundamental to security posture and operational resilience. By formalizing tracking processes, defining clear severity-based SLAs, and integrating GRC platforms, what could be an overwhelming manual compliance burden becomes a system of proactive, measurable security governance.
This approach ensures SOC 2 requirements are met for criteria like CC7.1 while building a stronger foundation, one where an effective security program is the basis, and compliance is the natural byproduct.
Build an Effective Security Program First
Get your ticketing, SLAs, and evidence architecture audit-ready with a structured approach that starts with an effective security program.
Book Your Strategy SessionFrequently Asked Questions
What ticketing system should I use for SOC 2 compliance?
Any ticketing system that provides an audit trail works: Jira, Linear, ServiceNow, GitHub Issues. The key requirements are consistent fields (severity, owner, timestamps), searchability, and retention. If you use a GRC platform like Vanta or Drata, choose a ticketing system that integrates with it for automated evidence collection.
How do I define SLA tiers for vulnerability patching?
Align SLA tiers with CVSS severity scores or your own risk classification. A common structure: Critical/High within 24 hours to 7 days, Medium within 14-30 days, Low within 60-90 days. Document these in your Vulnerability Management Policy and ensure they are realistic for your team's capacity. Auditors test whether you meet the SLAs you set, not whether they match an industry benchmark.
What happens when we miss an SLA?
Document the justification in the ticket (why it was missed, what compensating controls were applied during the delay, and the revised remediation timeline). A documented SLA miss with a clear rationale is far less concerning to an auditor than a ticket with no explanation or an SLA that appears to have been retroactively adjusted.
Do we need a GRC platform for SOC 2 ticketing and SLAs?
No. A GRC platform is not required, but it reduces manual effort significantly. Without one, evidence collection, SLA tracking, and audit preparation happen through spreadsheets and manual ticket reviews. With one, evidence flows from your ticketing system automatically, SLA adherence is tracked in real time, and audit-ready reports are generated on demand.
How does CC7.1 relate to ticketing and SLAs?
CC7.1 (Vulnerability Management) under the SOC 2 Trust Services Criteria requires controls to identify, assess, and remediate vulnerabilities. Your ticketing system with defined SLAs provides the evidence trail that proves remediation happens within your stated timeframes. Auditors sample tickets and check resolution times against your documented SLAs.
Get Your Evidence Architecture Right
Ticketing, SLAs, and evidence collection are the backbone of a SOC 2 audit. Find out how your current setup measures up.
Book Your Strategy SessionAbout the Author
