COSO Framework for Service Organizations and SOC Reporting (Part 1 of 3)

Jamie Kilcoyne, Managing Director Coalfire Controls

One of the most important reference tools that companies use to establish and evaluate their internal controls is the Committee of Sponsoring Organizations' (COSO) Internal Control - Integrated Framework.  Initially published in 1992 (the 1992 Framework), the COSO framework has been the most widely used model for internal control for the past 20 years.  Auditing standards followed by CPAs who delivered SAS 70 reports historically and now deliver Service Organization Control (SOC) 1, 2 and 3 reports require that elements of the COSO framework be considered and addressed in all SOC reports.  This generally appears in section 3 of SOC reports.  The 1992 Framework received additional recognition and prominence with the passage of the Sarbanes-Oxley Act of 2002.  Section 404 of the Act required publicly traded companies to evaluate their internal control over financial reporting relevant to a "recognized framework".  The 1992 Framework was selected by nearly every public company as the benchmark for evaluating controls and was also endorsed by the Securities and Exchange Commission.

In order to address the significant changes that have occurred in the past 20 years in technology and the business environment, COSO updated the 1992 Framework in 2013 (the 2013 Framework).  When the 2013 Framework was released, COSO provided guidance and recommendations about transitioning to the new framework by or before December 15, 2014.  After that date, the 1992 Framework is considered superseded by the 2013 Framework.

Just as public companies have had to transition to the 2013 Framework for their SOX 404 compliance efforts over the past year, service organizations who receive SOC 1, 2 or 3 reports also must make this transition.   Public companies have been required by their external auditors during the past year to map their historical control systems to the 2013 Framework.  Service Organizations have not been required to go to the same lengths and produce the same documentation as public companies, but CPAs who deliver SOC reports are also heavily focused on this when evaluating the design of controls and the description of service organizations' systems.

Three differences between the 1992 and 2013 Framework that impact service organizations will be evaluated in this post and 2 future posts:

  1. ​​Emphasis on understanding and evaluating controls of outsourced service providers (OSPs).
  2. Emphasis on risk assessment and fraud risk assessment.
  3. Emphasis on IT controls.
The first item above is likely the most relevant to service organizations who receive SOC reports and has the most over-arching impact.  COSO recognized that over the past 20 years there has been a massive shift in outsourcing and the use of OSPs.  As such, the 2013 Framework includes requirements for evaluating the controls of significant OSPs.  Companies that use OSPs (user entities) are now paying much more attention to the SOC reports of their significant OSPs.  And these user entities are expecting their OSPs to adopt the 2013 Framework and provide relevant information about it in the SOC report.  SOC auditors can guide their clients through this process and help them make the relevant updates to SOC reports and control components.


Another result of the increased emphasis on controls of OSPs in the 2013 Framework is that more and more service organizations are being required by their customers to provide annual SOC reports.  In the past, particularly when SAS 70 was still the de facto standard for service organization control reporting, audit reports were generally only required of the largest service organizations.  Now, the requirements are trickling down to smaller service organizations as their customers develop a greater appreciation of the importance of controls at OSPs.

In upcoming blog posts, we will evaluate how other changes in the 2013 Framework impact service organizations that receive SOC reports.

Thanks for reading!

Jamie Kilcoyne


Jamie Kilcoyne — Managing Director Coalfire Controls

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS