Don’t Fall for These SOC Reporting Myths
Published on by Bryan Gayhart, Morgan Hart, in SOC Reports, Video
Can’t watch the video? Get the transcript!
SOC reports provide valuable assurance to customers, prospects, lenders, and other stakeholders, but misconceptions can make getting started more confusing than it needs to be.
Is SOC a certification? Do you have to start with a Type 1 report? Does a SOC 2 need to include all five Trust Services Criteria? And can you share your SOC report publicly?
Barnes Dennig SOC professionals Morgan Hart and Bryan Gayhart tackle some of the most common SOC reporting myths and clarify what you really need to know.
Myth: SOC is a certification
While you might see companies claim to be “SOC certified,” a SOC examination is actually an attestation engagement governed by the AICPA. The CPA firm performing the engagement (more on that in a minute) provides an opinion on the design and implementation of controls and, for a Type 2 report, their operating effectiveness over a period of time.
The terminology may seem like a small distinction, but understanding what a SOC report actually represents can help you communicate more accurately with customers and prospects.
Myth: SOC 1 and SOC 2 are interchangeable
It’s a myth. SOC 1 and SOC 2 reports serve different purposes.
A SOC 1 report focuses on controls relevant to financial reporting, making it appropriate for organizations such as payroll providers and third-party administrators whose services can impact their customers’ financial statements.
SOC 2 reports focus on controls related to security and, when applicable, additional Trust Services Criteria like availability, confidentiality, processing integrity, and privacy.
Both SOC 1 and SOC 2 reports can be issued as either Type 1 or Type 2 reports. A Type 1 examines controls at a specific point in time, while a Type 2 evaluates how controls operate over a period of time.
Myth: A SOC 2 must include all five Trust Services Criteria
Security is the baseline for a SOC 2 report, but you don’t necessarily need to include all of the additional criteria.
Availability, confidentiality, processing integrity, and privacy can be added based on your operations, risks, customer expectations, and contractual requirements.
For many, starting with security and allowing the scope of the report to evolve as business and customer requirements change can be an effective approach.
Myth: SOC 2 criteria tell you exactly which controls to use
Unlike some other compliance frameworks, SOC 2 criteria aren’t highly prescriptive. The AICPA establishes the criteria an organization needs to address, but it doesn’t prescribe a specific set of controls that every organization must implement.
That flexibility means you can build a control environment appropriate for your operations and risk profile. It also makes thoughtful planning important, because the controls described in the report will be visible to report users. You should consider not only whether your controls address the criteria, but also whether they meet the expectations of your customers and other stakeholders.
Myth: you can’t start with a Type 2 Report
You actually can start with a Type 2 report, but you’re introducing additional risk.
Before the reporting period begins, you have to have your controls established, mapped to the appropriate criteria, and operating as designed. The system description also needs to be appropriately developed.
A readiness assessment and Type 1 engagement can help identify and remediate gaps before the Type 2 reporting period begins, potentially reducing the risk of testing exceptions or other issues.
Myth: A Type 2 reporting period has to be 12 months
A 12-month Type 2 reporting period is common, but it isn’t the only option. Under AICPA guidance, a Type 2 reporting period can be as short as three months, so the period examined depends on your business needs.
The appropriate period can depend on the type of SOC report, customer requirements, business cycles, and other considerations. For example, an organization may initially pursue a shorter SOC 2 Type 2 period to meet a customer requirement, then transition to a longer reporting period going forward.
Myth: A Type 2 report is a lot more work for the organization
You can get a lot of the heavy lifting done during a readiness assessment and the Type 1 process, when policies and procedures are being refined, controls are being established and mapped, and the system description is being developed.
During a Type 2 engagement, you’re generally providing evidence that those established controls operated throughout the reporting period.
For the auditor, however, a Type 2 typically involves more work because controls have to be tested over a period of time rather than at a single point in time.
Myth: Penetration testing is required for SOC 2
SOC 2 criteria don’t specifically require penetration testing. But that doesn’t mean you should automatically exclude it. Just like a lot of other elements in SOC reporting, it depends on your specific needs.
Whether penetration testing belongs in the control environment should be evaluated based on your organization’s risks, operations, and customer expectations. If you’re a technology company, your customers may expect to see regular penetration testing as part of a mature security program.
Myth: Anyone can issue a SOC report
SOC reports must be issued by a CPA firm. While other providers may offer SOC readiness or compliance services, a CPA firm must ultimately perform the attestation engagement and issue the report. And since they have to be comfortable with the work performed, that can mean additional time and expense.
When you’re evaluating SOC providers, be sure you understand who’ll be responsible for each stage of the process and who’s going to ultimately issue the report. A CPA firm’s peer review history can also provide valuable insight into its credibility and standing.
Myth: SOC reports can be shared publicly
SOC 1 and SOC 2 reports are generally confidential documents intended for specific users, such as customers and prospects, and are often shared under an NDA or similar agreement because they have a lot of confidential information about your organization’s systems and controls (not exactly something you want floating around on the internet).
If you need a public-facing report, consider a SOC 3. A SOC 3 provides a higher-level view of your organization and its control environment without the detailed controls and auditor testing included in a SOC 2 report, making it appropriate for public distribution.
Making SOC reporting more manageable
Understanding what SOC reporting does and doesn’t require can help you make better decisions about the scope, timing, and approach that fit your needs.
Whether you’re considering your first SOC report or planning the next stage of your SOC journey, getting the fundamentals right helps streamline the process, align the engagement with customer expectations, and build greater confidence in the final report. And that’s really the point, isn’t it?
If you have questions or are exploring the next step in your SOC journey, contact us for a free consultation with one of our top SOC reporting pros. As always, they’re here to help.
Related content
Beyond the myths, our SOC reporting FAQ covers the most common questions our pros hear. Download yours now. We also built a SOC reporting toolkit, packed with resources to help you navigate your next steps. And if video is your thing, we’ve got a huge library of SOC reporting videos for you to watch on-demand.
