Understanding SOC 2 Compliance and Its Impact on Your Atlassian Environment

Most companies assume that if Atlassian has SOC 2, they're automatically compliant too. That's the biggest misconception in this entire conversation.

A vendor's certification proves the vendor secured its side. It says nothing about your side - how you've configured access, who can see what, or whether your setup would actually hold up under an audit.

In this article, we'll break down what SOC 2 actually means, what Atlassian's report covers, and most importantly what your team actually needs to set up to close the gap yourselves.

What is SOC2?

SOC 2 specifies how organizations should manage client data to ensure security, availability, confidentiality, processing integrity, and privacy.

For a business, this isn't just a technical checkbox - it's a formal process with real steps and real deliverables.

Here's what it actually involves:

1. Choose your scope. You don't get audited on "everything" - you select which Trust Services Criteria apply to your business (security is mandatory; availability, confidentiality, processing integrity, and privacy are added based on what you actually promise your clients).

2. Fill out a readiness assessment. Before the real audit, most companies complete a gap assessment - a detailed questionnaire covering access controls, data encryption, incident response, vendor management, and employee onboarding/offboarding procedures. This identifies what's missing before an outside auditor sees it.

3. Contact a licensed CPA firm. SOC 2 audits can only be performed by a certified public accountant firm authorized under AICPA standards - not by an internal team, and not by just any security consultant.

4. Go through the audit. The auditor reviews your controls against the criteria you selected in step 1.

5. Receive your report. At the end, you get a formal SOC 2 report - a document you can share with clients and prospects under NDA, proving your controls are real and were tested, not just written in a policy document nobody follows.

SOC 2 Type 1 vs Type 2 - Why the Difference Matters

Type 1 checks if your controls are set up correctly but only on one specific day.

Type 2 checks if those same controls actually worked, every day, over a longer period (usually 3 to 12 months).

Think of it this way: Type 1 is a photo. Type 2 is a video.

A photo can look perfect - everything staged just right for that one moment. A video shows what really happens, day after day.

That's why most enterprise clients ask specifically for Type 2. It's proof that they're actually followed, consistently, over time.

For Atlassian products: this is exactly why Atlassian publishes Type 2 reports, not Type 1. Anyone checking Jira or Confluence's compliance wants to know the controls hold up over months, not just on the day of the audit.

SOC 2 vs SOC 3 - Which Report Do You Actually Need

What are your business objectives? That's the question your choice between SOC 2 and SOC 3 certification starts with.

Both SOC 2 and SOC 3 reports originate from the same established framework developed by the American Institute of Certified Public Accountants (AICPA), yet they are designed to serve distinctly different needs and audiences.

The Difference Between the Two Reports

A SOC 2 report is detailed. It includes the auditor's full opinion, a description of every control tested, and the actual results of those tests. It's meant for people who need that level of detail - your compliance team, your auditors, your security reviewers. Because it's so detailed, it's a restricted report: you can't just download it freely, you request it directly from the vendor.

A SOC 3 report covers the same criteria, but only gives a high-level summary. No detailed control list, no test-by-test results - just the auditor's overall opinion. Because there's nothing sensitive to protect, SOC 3 is a public report. Companies often publish it directly on their website as a general trust signal.

What Skills Your In-House Team Actually Needs

Getting either report especially if your own company is the one being audited - isn't a one-person job. You need:

• Someone technical, who understands how access, encryption, backups, and logging are actually configured
• Someone who can document policies - onboarding, offboarding, incident response, vendor management - not just describe what happens informally
• A project owner to coordinate the audit itself: deadlines, evidence collection, and communication across IT, HR, and legal

Most small teams don't have all of this in-house - which is why compliance automation platforms and outside consultants exist to fill the gaps. If the gap is specifically on the Atlassian side - access controls, audit logs, SCIM provisioning in Jira and Confluence - that's the part Softgile configures directly, so your team isn't figuring it out alone.

How to Actually Get the Report From Atlassian

Atlassian keeps every compliance document in one place: its Trust Center, at customertrust.atlassian.com.

For SOC 3: go to the Trust Center, open Certifications & Attestations, and download it directly. No NDA required - it's a public report.

For SOC 2: you'll be asked to sign an NDA through DocuSign before downloading. This step is known to glitch for some users - the NDA page spins and never lets you sign. If that happens, don't keep retrying. Open a support ticket directly through Atlassian Support, and their team will send the report manually.

Understanding SOC 2 Compliance and Its Impact on Your Atlassian Environment

SOC 2 evaluates organizations against five possible criteria, all defined by the AICPA (American Institute of Certified Public Accountants): Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Only one of them - Security - is mandatory for every SOC 2 report. The other four are optional. Each company decides which ones to include, based on what it actually promises its own customers.

Atlassian made that choice already. Its SOC 2 report covers three of the five: Security, Availability, and Confidentiality.

Security

This is the core of the report: protection against unauthorized access, unauthorized disclosure, and damage to systems. This is where access controls, authentication, and monitoring live — things like SSO (one login for every tool) and SCIM (automatic access removal when someone leaves). If you're checking Atlassian's SOC 2 report for one reason, it's this one.

Availability

Jira and Confluence are cloud services your team relies on every day. Availability confirms that system uptime holds up against Atlassian's own documented service commitments. For a SaaS product, this isn't optional in practice - even though AICPA technically lists it as one of the optional criteria.

Confidentiality

Roadmaps, internal discussions, strategy documents - this is exactly what Jira and Confluence store. Confidentiality confirms that information marked as confidential is actually protected the way your contract with Atlassian says it will be.

Where Atlassian's Responsibility Ends

SOC 2 tells you what Atlassian covers. It doesn't tell you what you still have to cover yourself.

What Atlassian handles:

• Security of the applications themselves — Jira, Confluence, and the rest of the Cloud suite
• The systems those applications run on
• The environments those systems are hosted within
• Ensuring those systems and environments meet standards like SOC 2, ISO 27001, and PCI DSS

What you handle:

• Who has access to your Jira and Confluence instances, and at what permission level
• How user accounts are created, changed, and removed
• What happens if an employee leaves — or if their credentials get compromised
• The data you choose to store, and how it's structured within your workspace

Atlassian Guard - closing the gap on your side

We just established the line: Atlassian secures the platform, you secure how it's used. Atlassian Guard exists specifically to help with your side of that line.

What it actually is

Think of it this way: if you have Jira, Confluence, and other Atlassian products, each one normally has its own separate admin settings. Guard sits on top of all of them - one place to control security across everything at once, instead of configuring each product separately.

What it covers

• Login security — enforcing SSO and MFA, so no one gets in with just a password
• Shadow IT detection — finding Atlassian products your employees signed up for on their own, outside of official channels, that you didn't know existed
• One audit log for everything — instead of checking activity separately in Jira, then separately in Confluence, you see it all in one place
• Threat detection — flags unusual account activity that might mean a compromised login
• Data classification — labels sensitive information so you know what needs extra protection

Why this matters for compliance specifically

Remember the access-related gaps we covered earlier — who has access, how it's granted, how it's removed? Guard is the tool that makes those things provable. When an auditor asks "how do you know only authorized people can access this," a centralized audit log is a much stronger answer than "we checked manually."

Teams using Guard alongside a properly configured Atlassian Cloud setup typically catch security issues faster, and don't scramble for missing documentation right before an audit.

Where Softgile Fits In

In this part of the article, we want to talk about what actually causes doubt and fear when SOC 2 comes up.

Here's a situation that probably sounds familiar: the auditor asks for your access logs, or how your SCIM setup handles offboarding - and your team realizes, right there in the middle of the audit, that something isn't ready.

That moment - not the audit itself, but the scramble it triggers - is where most of the real stress comes from.

Here's how Softgile helps you avoid it.

We configure the Atlassian side, before the auditor asks.

Not the audit itself, and not deciding which Trust Services Criteria apply to your business - that's the job of your CPA firm and compliance team. Our part is narrower, and it's the part that most often gets left half-finished: the actual technical setup inside Jira and Confluence.

What that looks like in practice:

• Setting up access controls and permissions so they match what you'd actually want an auditor to see - not what accumulated by accident over time
• Configuring SSO and SCIM through Atlassian Guard, so onboarding and offboarding are automatic, not something someone remembers to do manually
• Building an audit trail that's already there when it's needed - a report you can pull in minutes, not something your team assembles the night before

The difference this makes

You won't find out mid-audit that your access logs are missing something. You won't discover that someone who left the company still has access somewhere. You already know the answer -because the system is built to give it to you automatically."

If your compliance side is solid but you're not fully sure your Atlassian setup would hold up under a real audit, that's worth checking now - not during the audit itself.

‍