skip to content

7 common SOC compliance mistakes—and how to avoid them


As cloud computing service models and software as a service (SaaS) offerings continue to be adopted as cost‑effective, efficient technology solutions, customers of such companies are demanding high levels of assurance from service providers about the integrity, accuracy and reliability of the services provided to them—especially when sensitive financial information and private and confidential data are involved.

Such assurance is critical for risk management and mitigation at user entities, as they retain responsibility for any outsourced services. In highly regulated industries like financial services, third‑party compliance isn’t a nice‑to‑have; it’s a must‑have.

Cloud service providers can offer their clients the expected assurance through service organization control (SOC) reports.

SOC reports have become the market standard for third‑party attestations and can serve as a powerful testament to a company’s commitment to sound operating practices and its ability to meet regulatory and internal controls compliance, as well as market demands. SOC is increasingly becoming a necessary prerequisite to advance in the sales discovery and request for proposal (RFP) processes.

To guide you in your SOC attestation planning process, we have outlined some of the common pitfalls to avoid:

Service organizations with multiple services lines can provide a variety of different services, including cloud services, SaaS solution or data centre colocation services. A critical planning step that many service organizations fail to accurately complete is defining which services will be covered or excluded in the description of the system and by the SOC report. The boundaries of the systems addressed in SOC engagements may not be apparent. 

Therefore, the boundaries of a system addressed by SOC engagements need to be clearly understood, defined, documented, and communicated. For some SOC engagements, the system boundaries cover all the system components as they relate to a specific product or service lifecycle or may be restricted to a business unit or geographical location.

Once the boundaries and scope of the engagement have been defined, the next step would be to document the relevant aspects of the entity‑level components of internal control. These components include control environment, information and communication, monitoring, and risk assessment. 

Service organizations can use current sources of information about a company’s entity‑level components of internal control, including policies and procedures, code of ethics and related materials, corporate governance documentation and other related risk assessments. Management should categorize the information by the respective internal control components in simple and easy‑to‑understand language, leveraging report templates and guides that can be provided by the audit partner.

Once the internal control components have been described, management will need to develop a description of the key internal control elements of the system, including:

  • How the system was designed and implemented.
  • Infrastructure—the physical and hardware components of the audited system (facilities, equipment, and networks).
  • Software—the programs and operating software of a system (systems, applications, and utilities).
  • Data—the information used and supported by a system.

Depending on the maturity of the internal controls environment, service organizations may need to complete a readiness assessment before starting the audit. Facilitated by your audit partner, a readiness assessment is designed to uncover deficiencies and help you remediate them before the commencement of the audit. 

This will include reviewing various processes and controls that need to be identified to give you the opportunity to address any identified issues before the actual audit engagement begins. Certain remediation plans may include a redesign of processes and documenting evidence that controls exist and are operating as designed.

This relates to your clients’ or user entities’ responsibility of implementing controls at their end so the overall control objective can be achieved. A good example of a complementary user entity control is the management of client access to information systems. When clients are provided with access to your application system, they would need to have controls in place to ensure only authorized employees gain access and that access for terminated employees is immediately removed. 

This will allow you to communicate the control considerations and expectations to your clients and user entities so they’re aware of their responsibilities from a control perspective (e.g., clients and users are responsible for ensuring that user endpoints are protected against viruses and malware). Work with your auditor partner to determine the information that is suitable for inclusion as the complementary user entity controls.

Most organizations rely on subservice organizations to perform some of the services and behind the scenes support provided to the clients and user entities. A common service provided by a subservice organization would be a company that offers their data centre to a cloud service provider, or the provision of colocation managed hosting services. These considerations should be clearly identified at the planning stage.

SOC 2 reporting can be expanded to include additional subject matter specific to users’ unique requirements, such as Health Information Trust Alliance (HITRUST), ISO-27001 and National Institute for Standards and Technology (NIST). If planned properly, this audit approach can reduce compliance costs and efforts by streamlining controls testing and combining assurance reporting in one report.

How BDO can help

You want an SOC compliance partner that can work closely with you and tailor their approach to meet your unique needs and business requirements. It is critical to develop a solution that fits with the organization’s resources and needs, which includes leveraging existing templates and expertise to accelerate the process, identifying potential issues at the planning stage, and understanding the expectations of the end users. 

Contact us today for a preliminary assessment of your business requirements in determining which SOC report is right for you.

This site uses cookies to provide you with a more responsive and personalised service. By using this site you agree to our use of cookies. Please read our privacy statement for more information on the cookies we use and how to delete or block them.

Accept and close