SOC 2 (System and Organization Controls 2) Type II requires you to show that your controls worked throughout the entire audit period. Here’s how you can set up Jira to automatically collect that proof, using what we’ve learned from our own yearly audits.
Does Your Audit Evidence Live in Jira, or Just Pass Through It?
If your company uses Jira and goes through a SOC 2 audit, you might have noticed that most of the evidence auditors want—like change approvals, incident timelines, access requests, and offboarding tickets—already goes through Jira.
In this article, we’ll cover three main points:
- What SOC 2 Type II really looks for, explained simply, and why Atlassian is a good foundation for meeting those needs.
- How we handle SOC 2 Type II at SaaSJet. We go through this audit every year, and we manage most of these processes in Jira.
- A walkthrough of one real access request at SaaSJet, from request to audit evidence, followed by workflow examples for the other areas auditors check most often, plus how the SaaSJet portfolio helps you track everything from start to finish.
We aren’t auditors, so this isn’t official audit advice. What we share here is based on SOC 2 criteria, our audit experience, and our work with SaaSJet clients.
What is SOC 2 Type II, and What Do Auditors Really Look For?
SOC 2 (System and Organization Controls 2) is an independent review of how a company protects customer data. A licensed CPA (Certified Public Accountant) firm does the audit, using the Trust Services Criteria (TSC) from the AICPA (American Institute of Certified Public Accountants). The latest version is the 2017 TSC, updated with new points of focus in 2022.
First, we should understand the difference between SOC 2 Type I and Type II. SOC 2 Type I checks if your controls are set up correctly on one specific date. SOC 2 Type II checks if those controls worked well over a period of time. The AICPA doesn’t set a standard length for this period: 3, 6, and 12 months are common, and you decide the timeframe with your CPA firm. Most enterprise customers expect Type II.
The Five Trust Services Categories of SOC 2 Type II
Category | Required? | What it covers |
|---|
Security (the Common Criteria, CC1–CC9) | Always | Protection of systems and data against unauthorized access |
Availability | Optional | Systems are available as committed: capacity, backups, recovery |
Processing Integrity | Optional | Processing is complete, accurate, and timely |
Confidentiality | Optional | Confidential information is protected |
Privacy | Optional | Personal information is collected and used properly |
This article is focused on Security and Availability: Security because it's always in scope, and Availability because backups and recovery testing are where many teams struggle to show evidence.
Why SOC 2 Type II Is Harder Than It Looks
First, it's important to understand that auditors don't ask you to submit every ticket. They ask for the full population of an activity (every change, every incident, every leaver in the period) and pick a sample from it. Then they trace each sampled item end to end.
That changes what "ready" means. It isn't enough for most tickets to be clean. Every record has to be complete, because you don't choose which ones get checked.
Where SOC 2 Meets Atlassian Products
Criterion | What it says | What the auditor asks for | Where it lives in Atlassian |
|---|
CC8.1 Change management | Changes are authorized, tested, approved, and implemented | A sample of changes with approval before release | Jira: release, hotfix, and infrastructure change work items, approval transitions, linked pull requests |
CC7.2–CC7.5 Incident management | Detect, evaluate, respond to, and recover from security incidents | Incident list, response timelines, post-incident reviews | Jira / JSM: incident work items and timelines. Confluence: post-incident review pages, incident response procedure |
CC6.2, CC6.3 Access management | Authorize access before granting it; remove it when no longer needed; apply least privilege and segregation of duties | Access requests with approvals, on-time offboarding, access reviews | Jira / JSM: access request, offboarding, and access review work items |
A1.2, A1.3, CC9.1 Availability and continuity | Manage backups and recovery infrastructure; test recovery plans | Proof that restore tests and DR (disaster recovery) exercises happened on schedule | Jira: recurring restore test work items. Confluence: backup and business continuity procedures, DR exercise reports |
CC1.4, CC2.2, CC4.1, CC5.3, CC9.2 Recurring controls | Training, internal communication, ongoing evaluations, policies, vendor risk | Completion records for trainings, internal checks, policy and vendor reviews | Loom: training recordings. Jira: training completions, internal checks, vendor reviews. Confluence: policies with version history |
Why Atlassian Is a Solid Base for SOC 2 Work
If you plan to build SOC 2 evidence using Jira, it makes sense to first check if the platform itself meets those standards.
- Atlassian provides its own SOC 2 reports. These reports cover Jira, Confluence Cloud, Jira Service Management, and other cloud products. You can access them through Atlassian’s Trust Portal.
- Jira keeps a native history that cannot be edited. Every change to a field or status on a Jira work item is saved in the change log, and users are not able to alter this record.
- SOC 2 compliance is a shared responsibility. Atlassian’s SOC 2 report covers its own platform, but you are responsible for your own controls, such as who approves changes and how quickly you revoke access. Vendor SOC 2 reports usually explain which controls customers need to manage themselves. You will set up and demonstrate these controls in your own Jira environment.
The same approach applies to apps. SaaSJet apps run on Atlassian Forge, which means your data remains in your Atlassian tenant. SaaSJet also has its own SOC 2 Type II report, which you can find at the SaaSJet Trust Center.
Our Own Use Case: How SaaSJet Runs SOC 2 Type II in Jira
SaaSJet (my company) goes through SOC 2 Type II every year, and most of our evidence collects in Jira. Here's what that looks like at a process level.
Criteria codes come from the AICPA Trust Services Criteria (CC = Common Criteria).
Process | SOC 2 criteria | How it runs at SaaSJet | The target we hold ourselves to |
|---|
Change management | CC8.1 | Every new release and hotfix goes through its own workflow in the space of the product it belongs to, with peer review and approval before release. If there is an emergency, steps can be skipped with the incident commander's approval. | Any skipped steps must be completed and reviewed within 5 business days. |
Incident management | CC7.2–CC7.5 | A work item is opened as soon as an incident is detected. It's filled in while the problem is being resolved, and the post-mortem is documented in the same work item. That one work item becomes the full record of what happened and how it was fixed. | One work item per incident, from detection to post-mortem. |
Background check | CC1.4 | A separate work item is created at the final stage of hiring, for shortlisted candidates or the selected candidate. It records that the check was completed, when and by whom. | No employment is confirmed before the background check is completed. |
Onboarding | CC1.4, CC2.2, CC6.2 | One work item per new hire covers company policies, security training and account creation. Onboarding includes both the company and the product, so it runs longer than the first day. Access to tools is requested in a separate Access work item. | No onboarding work item is closed until every step on the HR checklist is done. |
Access requests | CC6.2, CC6.3 | Every request has a named approver who approves before access is granted. The person who asked for access checks that it works before the request is closed. | No access without a recorded approval, and no closed request without the requester's confirmation. |
Offboarding | CC6.2, CC6.3 | We use a checklist for each person that lists every system the employee accessed, rather than a generic list. | We revoke all access within 24 hours after the employee's last working moment. |
Backups and recovery | CC9.1 | We regularly test restores in an isolated environment. | We test restores at least every quarter and run a business continuity exercise once a year. |
Access reviews | CC6.3 | Reviews are scheduled based on how critical each system is. The reviewer is always someone other than the system owner. | Critical systems are reviewed every quarter, major systems every six months, and minor systems once a year. |
Policy and vendor reviews | CC5.3, CC9.2 | Reviews are spread throughout the year instead of being done all at once before an audit. | We review every policy and active vendor once a year. |
Many of our recurring processes have used a tool our team built for years. Everything described below can also be set up using native Jira and the apps we mention.
A Step-by-Step Guide: How an Access Request Becomes Audit Evidence
We would like to share a practical example of how SaaSJet uses Jira to manage access requests and what auditors see at the end. Our Jira workflow is simple: TO DO, APPROVED, IN PROGRESS, TO REVIEW, and DONE.
- The request. An employee creates a work item of the Access type. Custom fields collect the details that auditors will need later. Here are some examples:
Custom Field | What it records |
|---|
Affected employee | Who the access is for |
Affected Service | Which system or tool |
Access action | What's being done, for example granting or changing access |
Type of access | The role or permission level |
Access period | Permanent, or until a set date |
We chose these fields based on what our auditors usually ask for. Your fields may be different, depending on your controls and your auditor’s needs. Start by listing the questions you expect and add fields for each one.
- Approval. The Approvers custom field lists who needs to approve. The approver is the requester's manager. An automation rule adds a comment, tags the approver, and asks for approval. The approver then comments to approve, tags the assignee and moves to the APPROVED status.
- Provisioning. The assigned system administrator gives access and tags the requester. Only specific people are allowed to grant access, so it never comes from just anyone with admin rights.
- Verification. The requester checks if the access works and matches what was requested. If everything is correct, the work item moves to DONE. If not, it returns to IN PROGRESS.
- Documentation. When the work item is marked as DONE, an automation rule tags the assignee with a reminder: "Check whether the documentation in Confluence is updated. If not, please update it." This is our own practice, not something the auditor asked for. Every closed request gets this reminder, and there's a record that it was sent. It keeps our access documentation current between audits.
- The audit question. In real audits, auditors do not begin with just one access request. Instead, the company gives them a population report, which lists everyone who worked at the company during the audit period. The auditor then selects a sample based on hire and leave dates. For each new hire, they check how access was given. For each person who left, they check how access was removed. During the time in between, they see if access is reviewed regularly. For example, the auditor might say,"Show us how access was granted to this employee."
Using the Issue History for Jira app, we select the work items with JQL:
reporter = "Employee name" AND type = "Access" AND created >= -90d
For an employee from the audit sample, replace -90d with their start date, so the report covers their access from day one.
The report shows every action on those requests: the approver’s comment, the assignee’s status changes, and the requester’s confirmation. Next, we pick the columns the auditor needs (status, assignee, Approvers, description, comments) and get the audit-ready report in minutes instead of searching through comments.
In one real example, the report showed the entire process in one view: the request was created, automation tagged the approver, approval happened three minutes later, the assignee changed the status the next day, the requester checked in TO REVIEW, an automated reminder was sent to update Confluence, and the request was reopened when the access was incomplete. Every entry has a name and a timestamp, even those added by automation.
The access request is only the first link. It shows who asked, who approved and who granted access. Next, the auditor checks the access itself inside each service. A complete record in Jira makes that step easier, because every access they find should match a request.
Which SOC 2 Processes You Can Run in Jira
The walkthrough covers one SOC 2 process. Here are some workflow examples for other areas that auditors often review. The status names are just suggestions. Adjust them for your team, and make sure each step creates a timestamped record.
Change Management in Your Release and Hotfix Workflows
For CC8.1, auditors focus on the steps before production, not how a feature was built. They check if changes were reviewed, tested, and approved before release. You don’t need a new workflow—just make sure your current release and hotfix workflows follow these rules.
There is one workflow with two possible paths:
Standard path: TO DO → IN DEVELOPMENT → IN REVIEW → READY FOR TESTING → TESTING → APPROVED → RELEASED → DONE
Emergency path: TO DO → IN DEVELOPMENT → EMERGENCY APPROVED → RELEASED → RETROSPECTIVE REVIEW → DONE
Only the incident commander can use the emergency transition, and only when the Change Type is set to Emergency. After release, an automation rule moves the change to RETROSPECTIVE REVIEW. This way, any skipped review and testing steps are completed before closing the change.
READY FOR TESTING and APPROVED (which means approved and waiting for release) are considered waiting statuses. When someone finishes their part, they move the work item to a waiting status and assign it to the next person. Each handoff is recorded in the work item's history. And then, for instance, Time in Status by SaaSJet helps you see the difference between time spent waiting in a queue and time spent working on the change (see Diagnose below).
Rule | Why the auditor cares |
|---|
Approval comes before release, with no transition around it | Proves every change was authorized before it reached production |
The person who approves isn't the author of the change | Segregation of duties |
Review and test results are linked to the work item (pull request via the development panel) | Proves the change was reviewed and tested, not only approved |
Emergency changes have their own path, and the skipped steps are completed afterwards in RETROSPECTIVE REVIEW | Fast-tracked changes are where evidence most often breaks |
Every release and hotfix is tagged with Control ID = CC8.1 | One filter returns the full population of changes across all product spaces |
For example, using the JQL query "Control ID" = "CC8.1" AND created >= startOfYear() will show every release and hotfix in all product spaces during the audit period.
Helpful custom fields include Change Type (Standard or Emergency), which lets emergency changes follow a separate process, and Rollback Plan, since CC8.1 requires changes to be designed, approved and documented.
Automation can help by moving an emergency change to RETROSPECTIVE REVIEW and assigning it to the technical lead once it is marked as RELEASED.
The Infrastructure Change Workflow
Some production changes don’t begin as a story or bug. These might be a cloud setting, a network rule, or a manual database fix. Auditors sample these changes too, but they are often missed. Make sure to track each one as an Infrastructure Change work item, or use JSM’s built-in change management, and follow the same rules as releases.
One workflow, two paths:
Standard path: OPEN → IN ANALYSIS → IN REVIEW → APPROVED → IMPLEMENTED → DONE
Emergency path: OPEN → EMERGENCY APPROVED → IMPLEMENTED → RETROSPECTIVE REVIEW → DONE
Status | Who moves it | What it proves |
|---|
IN ANALYSIS | Change owner | Scope, impact, and rollback plan were documented |
IN REVIEW | A second engineer | Someone other than the author checked the change |
APPROVED | Technical lead or service owner | Someone authorized the change, and who it was |
IMPLEMENTED | Change owner | The change was applied in production, after approval |
EMERGENCY APPROVED | Incident commander | Fast-track approval, with the skipped steps flagged |
RETROSPECTIVE REVIEW | Technical lead | The skipped steps were completed after the fact |
The Security Incident Workflow
The next process is incident management. Here is what the workflow might look like:
REPORTED → TRIAGE → CONTAINMENT → RESOLVED → POST-INCIDENT REVIEW → CLOSED
Phase | Criteria | What it proves |
|---|
REPORTED → TRIAGE | CC7.2, CC7.3 | The event was detected, evaluated, and classified by severity |
CONTAINMENT → RESOLVED | CC7.4, CC7.5 | A defined response ran: contain, fix, communicate |
POST-INCIDENT REVIEW | CC7.4, CC7.5 | Root cause and corrective actions were documented |
Helpful custom field for this Jira item is Severity. This determines response targets and who needs to be involved. A useful setup is to attach both the Intake form and the Root Cause and Closure form when the incident work item is created. The first is filled in at detection, the second during the post-mortem, so the incident and its post-mortem stay in one record.
HR Workflows: Background Check, Onboarding, Offboarding
HR processes are included in SOC 2 as well. Auditors often select a few new hires and employees who have left, then ask for evidence that each step was completed. When each person has a work item, finding that proof is quick and easy.
The Background Check Workflow
A background check helps show that the company hires trustworthy people (CC1.4). Here’s how the Jira workflow looks:
REQUESTED → IN PROGRESS → COMPLETED → CLOSED
Set up the work item before confirming employment. Just record the status, date, and who confirmed it. Store the background check report outside Jira, and use issue security levels to control who can view these work items.
A useful custom field here is Check Completed On (date). This shows the check was done before the person’s start date.
The Onboarding Workflow
Onboarding is the first step in access management (CC6.2). It also includes policies and training (CC1.4, CC2.2). Here’s the Jira workflow:
SCHEDULED → IN PROGRESS → DONE
For each new hire, use a checklist that covers policy acknowledgment, security training, and account creation. Request access to tools using your access request workflow, and link those work items to onboarding so everything stays organized.
A helpful custom field here is First Working Day (date). This marks when onboarding begins.
The Offboarding Workflow
Offboarding is the second part of access management (CC6.2). It means removing access when it is no longer needed. The Jira workflow:
SCHEDULED → REVOCATION IN PROGRESS → ACCESS REVOKED → CLOSED
Start REVOCATION IN PROGRESS at the employee’s last working moment to keep timing accurate. Use a checklist for each person that lists every system they had access to.
In this case, helpful custom field might be Last Working Moment (date and time). This marks the start of the revocation clock.
The Control Check Workflow (Recurring)
SCHEDULED → IN PROGRESS → VERIFICATION → PASSED / ISSUES FOUND → CLOSED
One workflow can be used for every recurring control. The only thing that changes is the checklist attached to it (see Smart Forms below). If ISSUES FOUND is selected, it links to a remediation work item that is tracked until it is closed.
Create the work item once, then use Set to recur (from the automation icon or the due date field) to choose how often it repeats. Jira will create a new copy on schedule, and Smart Forms will attach a new checklist to each one.
Note helpful Jira fields: Review Decision (Approve, Revoke, Downgrade, or Transfer) for access reviews, and Next Review Date, which keeps the schedule visible so nothing is missed.
The Policy Approval Workflow
A policy is valid only after management approves it (CC5.3), and employees are informed about it (CC2.2). Here is the Jira workflow:
DRAFT → IN REVIEW → APPROVED → PUBLISHED
Store the policy text in Confluence and link that page to the work item. Add required approvers to the Approvers field, and let only them move the work item to APPROVED. Once it is PUBLISHED, set up an automation rule to create acknowledgment tasks or send the link to everyone who needs to read it.
The Risk Review Workflow
SOC 2 requires you to identify and analyze risks (CC3.2) and show how you reduce them (CC9.1). Each risk should have its own work item. The Jira workflow is:
IDENTIFIED → ASSESSED → IN TREATMENT → MONITORED
Review risks regularly and update their ratings each time. You do not need to create a new work item for every review. Issue History for Jira tracks how Likelihood and Impact change over time and who made the changes. This shows your risk assessment is kept up to date, not just done once.
In this situation, useful custom fields include Likelihood and Impact (select lists) and Risk Owner (user).
Three Rules That Make Any Workflow Auditable
- Do not add a transition that skips the approval step, such as moving from IN REVIEW directly to RELEASED. If approval is always required in the workflow, there is nothing to explain to the auditor.
- Restrict who can approve. Only allow the right roles to approve, and do not let the author or requester approve their own change or request. This ensures segregation of duties (CC6.3) within the workflow.
- Tag every work item with its criterion. Add a Control ID field (CC8.1, CC6.2, etc.) to every relevant work item, in any space, so you can filter by population. See the example in the change management section above. If all your SOC 2 work is in one space, you can also create a separate board for each work item type, with a column for each status in its workflow.
Diagnose: Find Where Your Controls Slow Down with Time in Status
Even if a control works, it can still be risky if it takes too long. For example, an access review might stay in IN PROGRESS for three weeks, or a restore test could get stuck in VERIFICATION.
Tracking time in each status helps the team that owns the controls answer three important questions:
- "How long was it waiting, and how long was it worked on?" You can group waiting statuses like READY FOR TESTING and APPROVED, and active ones like IN REVIEW and TESTING, to see how much time a change spent in a queue. The Time in Assignee report also shows how long each person had the work item, making every handoff easy to track.
- "Where does the process stall?" You can group statuses, such as IN PROGRESS and VERIFICATION for a restore test, to measure actual recovery time and compare it to your RTO (Recovery Time Objective). Average Time helps you spot bottlenecks over time.
- "How often did a step fail?" Status Count and Transition Count reveal rework, such as access requests sent back from TO REVIEW when access fails, or changes returned from TESTING. If you see a repeating loop, it's a control to fix before the next audit period.
Time in Status by SaaSJet shows where processes slow down, wait, or loop back, so you can fix them before they show up as exceptions in your SOC 2 report. If you review these numbers regularly and record the review, that record can also support CC4.1 (ongoing evaluation of controls).
The new Forecast feature answers one more question: "Will open work finish on time?" Forecast adds up the time similar completed work items spent in the statuses you select, takes the median, and uses it to estimate an end date for each open item. It then compares that date to a target date like the Due date. If you compare by work type, you can see which open access reviews or remediation tasks might miss their deadline while there is still time to act. Results appear in the Forecast by Time in Status dashboard gadget. (This feature is available on the Advanced plan. Forecasts need enough completed history, so rare controls may show Low confidence.)
Audit: Build an Immutable SOC 2 Audit Trail with Issue History for Jira
If an auditor reviews 25 changes, you should have a complete record for each one, ready to share.
Issue History for Jira by SaaSJet does not keep its own copy of your data. Instead, it reads Jira's built-in change log, which users cannot edit, and creates a report showing the old value, the new value, who made the change, and when. This makes the report unchangeable. No one can quietly remove information before an audit.
Audit question | What Issue History shows |
|---|
Was this change approved before release? | Every status transition, with the user and timestamp |
Did anyone edit the incident record afterwards? | Field changes, comments, and attachments; deleted comments stay visible in the report |
Were requester and approver different people? | Each change is attributed to a named user, including changes made by automation rules |
What happened to work items that were deleted? | With Keep deleted work items on, deleted work items stay in the report |
Can we hand over the full population? | Filter by space, user, and date range; export to XLSX or CSV |
Who approved this access request, and when? | The approval comment with its author and time, plus any change to the Approvers field, so you can see if the approver was changed afterwards |
Who handed the work to whom? | Every assignee and status change, with a timestamp: each handoff between developer, tester, and approver |
Monitor Commitments: Keep Every SOC 2 Deadline on Track with SLA Time and Report
A policy deadline only matters if you can prove it was met every time. In SOC 2, these deadlines are spread out. Incidents and access requests are usually handled in Jira Service Management, which has its own SLAs. Meanwhile, many controls are managed in Jira Software, like release and hotfix workflows, emergency change reviews, recurring access checks, and restore tests.
SLA Time and Report by SaaSJet puts all these deadlines under one set of rules, no matter which Jira space you use. Each deadline works like a clock with its own start, stop, pause, and calendar.
SLA goal | Starts | Stops | Calendar | Target |
|---|
Incident response | REPORTED | TRIAGE | 24/7 | Your policy, per severity |
Incident resolution | REPORTED | RESOLVED | 24/7 | Your policy, per severity |
Post-incident review | RESOLVED | CLOSED | Business days | Your policy |
Offboarding revocation | REVOCATION IN PROGRESS | ACCESS REVOKED | 24/7 | 24 hours (ours) |
Emergency change retrospective | RETROSPECTIVE REVIEW | DONE | Business days | 5 business days (ours) |
Remediation after a failed check | Linked remediation created | Remediation done | Business days | Your policy |
Recurring control check | Work item created | DONE | Business days | Due date (Negotiated date goal): monthly, quarterly, or annual |
- Get alerts in time to act. Notifications appear as comments on the work item, so if offboarding is running late or a recurring check is overdue, you can catch and fix it before it becomes a problem.
- Track progress over time. The met, in progress, or exceeded report lists every goal for the observation period. You can export the report or set up the Report Scheduler to send it regularly, so you build up evidence each month.
Automate: Complete Information at Every Stage with Smart Forms for Jira
Auditors need to trace every record from the beginning. When, for instance, incident reports are written in free text, they often look different and sometimes lack important details. Smart Forms by SaaSJet solves this in three ways:
- You get the right questions at the right time. A single work item can use more than one form. For example, a Security Incident starts with an Intake form when reported, then uses a Root Cause and Closure form during review. Conditional logic makes sure only relevant questions appear, like extra containment questions showing up only if the severity is High.
- You don’t have to enter the same information twice. Form fields can fill themselves in using Jira fields already on the work item, like the reporter, affected system, or severity.
- Answers can trigger the next step. They stay in the form, so you don’t need a custom Jira field for every question. Only key answers, like Severity, are sent to Jira fields for filters, SLA goals, or automation. When you submit a form, Smart Forms can update those fields.
Forms you can use in this setup:
Form | Attached to | What it captures |
|---|
Incident Intake | Security Incident | What was detected, affected systems, severity; conditional questions for high severity |
Root Cause and Closure | Security Incident | Root cause, timeline, corrective actions and their owners |
Access Request | Access | System, role, business justification (required) |
Offboarding Checklist | Offboarding | One line per system, with a field for the deactivation export |
Restore Test | Control Check | What was restored, completeness, who verified |
Access Review | Control Check | User, role, decision, action taken |
Training and Knowledge Check | Control Check | Course completed, quiz answers |
Three settings make the forms audit-ready:
- Auto-attach. A form is added automatically when a work item of its type is created. That includes the copies Jira creates with Set to recur, so every quarterly check gets a fresh checklist.
- Locked responses. By default, nobody can edit a response after it's submitted.
- Roles. Owner, Editor, Collaborator, Submitter, and External roles control who can change the form and who can see the responses.
Back to Diagnose: The Next Audit Period Has Already Started
SOC 2 Type II is more than just getting the report. Take a look at your data to figure out what needs improvement before the next observation period. Focus on missed SLA goals, stalled work statuses, and forms that are often incomplete. After making changes, check again to see if they worked. This is the ongoing process.
SOC 2 and DORA: What Carries Over
If you also serve EU financial entities, much of this setup does double duty. DORA (Regulation (EU) 2022/2554) covers the same ground (incidents, changes, access, recovery testing, vendor risk) but adds fixed notification deadlines to regulators. We covered that in How to Set Up Jira for DORA Compliance: ICT Incident Reporting and Audit Trails.
Make Jira Produce the SOC 2 Evidence
A SOC 2 Type II audit isn’t just about a single ticket. It begins with a population report, a sample, and a request to track each item from beginning to end. That’s why every record needs to be complete, not just most of them.
Jira’s built-in features cover the basics: workflows that require approval, fields that answer auditor questions, a Control ID for each population, and simple automation for reminders and handoffs. At SaaSJet, we use this setup for changes, incidents, access requests, and HR processes, from background checks to offboarding.
SaaSJet apps bring everything together in a single Workflow Intelligence cycle:
- Diagnose with Time in Status: see where controls slow down or loop back.
- Audit with Issue History: turn Jira's change log into a record nobody can edit.
- Monitor commitments with SLA Time and Report: get reminded before a deadline is missed, and prove the ones you met.
- Automate with Smart Forms: make every record start complete, including each recurring check.
After that, you return to Diagnose as the next audit period begins.
These tools alone won’t make your company SOC 2 compliant. You set the controls, and your auditor tests them. But when the auditor selects a name from the sample, you should be able to respond with a filter and an export, not spend a week gathering screenshots.
How does your team gather SOC 2 evidence in Jira? Share your approach in the comments.
