SOC Reports can vary in difficulty, depending on the systems and processes unique to each organization. This can lead to confusion when in the throes of an audit. Through each of the Trust Services Criteria, we’ll review some areas within each criterion that we have observed difficulty in – whether that be difficulty in implementing sufficient controls or in evidencing controls that have been implemented. We’ll also identify some controls to address the difficulties or best practices around evidencing controls based on our experience working through these confusions with clients, along with some illustrative examples of where our clients went from confusion to compliance.
Security
Risk Assessments
- Confusion: Conducting a thorough risk assessment can be daunting and it’s easy to settle for a “check the box” process to fulfill the audit requirements.
- Compliance: Perform risk assessments using an established framework, such as NIST CSF v2.0, to allow for structured outputs that can help with informed decision-making and proactive risk mitigation. Having a third party perform the assessment provides both objectivity and decreases workload on security/compliance personnel who would be otherwise performing the assessment.
Logging and Monitoring
- Confusion: Continuous monitoring of controls and systems requires resources and expertise. While tools can aid in logging and alerting, if logs or alerts aren’t reviewed, the logs serve no purpose.
- Compliance: Monitoring Controls: Implement monitoring controls to regularly review logs and alerts from systems for potential malicious activity. This proactive approach to security offers an effective control that can catch bad actors before they do irreparable damage.
Access Controls
- Confusion: Depending on the organization, access management processes could be spread between many systems and control owners, each with its own process. Additionally, some (usually older) systems do not retain the date accounts were created.
- Compliance: Enforce Consistent Access Controls: Implementing consistent access controls across all systems in an organization allow for more efficient management of the systems and consequently, easier auditing. Additionally, enforcing common access controls can help quell the presence and risks of Shadow-IT.
User Access Reviews
- Confusion: While not required for SOC, user access reviews are an excellent mitigating control should deviations arise in provisioning or deprovisioning processes. However, many organizations struggle defining the scope and frequency of the user access review process.
- Compliance: Regular Comprehensive User Access Reviews: The user access review process should designed with the various user types and systems in mind. For example, privileged users are at higher risk of misuse and should be reviewed more frequently. Additionally, each user should be reviewed with their permissions in context. This allows for contextual decisions around the roles they currently maintain. The results and any remediation activities should be formally documented to ensure actions taken were completed.
Change Management Separation of Duties
- Confusion: This is another area many organizations, particularly those with smaller development teams, struggle with. Smaller teams may require developers to deploy as well, and while policy may dictate a secondary approval must occur or another individual must deploy, the risk of an unauthorize and undetected change to production is still present without preventative or monitoring controls in place.
- Compliance: You can have the best change management process in the world, but if users bypass it, it may result in a qualified opinion from your auditor. Ensure users cannot bypass change management controls through one of the two:
- Preventative Control: logically restrict the ability of developers to deploy to production through security gateways in the deployment process or through preventing access to deployment tools. This should be tailored to your organization’s unique deployment processes.
- Detective Control: While the preventative control is ideal, if not feasible, a detective control should be implemented to identify if an individual is circumventing the change management process. This could be as sophisticated as a tool monitoring the ticketing system and production to ensure all production changes have associated tickets to as simple as alerts being sent to management on all deployments.
Illustrative Example: A client added a new system to their SOC report and through the course of testing, it was identified that the system was not following the organization’s standard access controls. The process in place for managing access was reliant on personnel periodically reviewing an HR report, and consequently, terminated employees could be present within the listing for up to two weeks. After identifying this, the Security team committed to bringing the system into their standard processes to mitigate the risk of potential terminated employee access persisting in the system.
Availability
Capacity Logging and Monitoring
- Confusion: Similar to system event logging and monitoring, if threshold alerts are not monitored and responded to, the logs serve no purpose.
- Compliance: Capacity monitoring can be tricky depending on the infrastructure of an organization. For more traditional on-prem organizations, ensure capacity thresholds are tuned and alert appropriate personnel timely so that action can be taken before an outage occurs.
Backup Tool Complexities
- Confusion: Some backup tools do not provide the easiest reporting capabilities and are not intuitive for audit purposes. This can be particularly challenging for organizations with large amounts of virtualized resources that need to be backed up at different intervals.
- Compliance: Gain a sufficient understanding through discussion with backup system owners on the systems that are backed up, how the tool configures backups, and what reporting capabilities the tool allows. If backups are fully automated, your auditor may be able to test backups as an automated control.
Formal Disaster Recovery Plan
- Confusion: Creating and maintaining a comprehensive disaster recovery plan is resource intensive.
- Compliance: While not strictly required to meet the Availability Criteria, conducting a Business Impact Analysis (BIA) and developing a Business Continuity Plan (BCP) significantly supports the creation of an effective Disaster Recovery Plan (DRP). The BIA identifies critical operations and recovery priorities, which informs the BCP’s strategies for maintaining those operations during disruptions. If a disruption escalates into a disaster, the DRP provides the technical details to restore IT systems that support the functions outlined in the BIA and BCP.
Disaster Recovery Testing
- Confusion: Disaster Recovery processes often require input from many different groups within an organization such as Management, IT, Facilities, HR, Legal, Public Relations, Security, and various involved departments. Coordinating a time for these individuals to all meet and exercise the Disaster Recovery Plan can be challenging.
- Compliance: The testing of recovery plans is a requirement of SOC (A1.3). Emphasize the importance of testing the DRP to management. Some efficiencies can be gained by consolidating DRP testing with Incident Response Tabletop testing as an incident will more than likely precede a disaster. Additionally, to provide objectivity and outside expertise, third parties, like LBMC, can be brought in to proctor the simulation and provide realistic scenarios tailored to your organization.
Illustrative Example: A client was using an older version of a backup management tool to manage a significant number of virtual machines. We encountered two main issues through testing. The first was that most reporting within the backup tool was at the hypervisor level, thus we couldn’t easily tie our sampled virtual machines easily to configurations reported. The second was that due to the sheer number of backups, history reports were often purged throughout the testing period. However, through various discussions with the backup engineers, we were able to observe the backup tool and identify the backup configurations that applied to our sampled virtual machines. The backup configurations contained detail which gave us comfort the configurations had not changed within the test period. We were then able to review an example backup execute for each of the samples and through this automated testing approach, we were able to complete our testing in that year and subsequent years with less impact to the control owners.
Confidentiality
Data Classification Gaps
- Confusion: Without a formal classification system, employees often don’t know what qualifies as confidential. For example, proprietary business plans or customer lists may be stored and shared like regular documents, unlabeled, unencrypted, and widely accessible.
- Compliance: Organizations should implement a formal data classification policy defining categories such as Public, Internal, Confidential, and Restricted. Automated tools can consistently discover and label sensitive data. Employees must be trained to apply these labels during document creation, and systems should enforce access controls based on classification.
Unstructured Data
- Confusion: Confidential data frequently resides in uncontrolled environments like email attachments, chat messages, shared folders, or legacy systems that lack effective monitoring, increasing the risk of leaks.
- Compliance: Deploy data loss prevention (DLP) solutions across endpoints, cloud storage, and collaboration platforms.
- Automate data deletion, archival, or purging systems. Securely destroy physical documents via cross-cut shredding and digitally erase data using DoD-compliant wiping or cryptographic erasure.
Illustrative Example: A regional financial services firm engaged LBMC after discovering that sensitive client financial records were being shared internally via unsecured email, risking a breach of confidentiality. LBMC conducted a thorough review of the firm’s data handling practices and identified gaps in internal access controls and communication protocols. They implemented secure file-sharing solutions, established role-based access restrictions, and trained employees on confidentiality best practices. These measures significantly reduced the risk of unauthorized data exposure and strengthened the firm’s overall information governance.
Processing Integrity
Technical Expertise
- Confusion: Processing jobs/configurations may be developed and managed in a way which requires the developer’s technical expertise to evidence and understand.
- Compliance: These are individuals with access to the systems or code that govern data processing. They can confirm how obligations are met and help auditors understand the control environment.
Reporting Capabilities
- Confusion: Fail to retain historical data, complicating audits for Type 2 reports.
- Compliance: Auditors may use Sample-based testing: Auditors may use sample-based testing or automated testing, depending on the system and processes audited.
- Sample-based Testing: Ensure systems can produce a population of occurrences over the course of the testing period and that selections provided by the auditor can be pulled from the system.
- Automated Testing: Ensure the related configuration/job can be provided to the auditor, the configurations have remained unchanged throughout the testing period, and that an example can be produced to demonstrate configuration/job works as intended.
Illustrative Example: We performed a SOC 2 report for a healthcare client who processed claims . The system was older, and many different individuals had ownership at various parts of the process. Both auditors and auditees struggled for the first couple years with the processing integrity controls due to variations in both the jobs used to process claims and the contractual requirements around the claims varied by our client’s clients. Through year over year audits, the teams at both LBMC and the client ironed out control owners and contractual obligations, which allowed us to focus in on defining control statements that were both testable and accurate to the client’s obligations to its customers. LBMC was able to gain comfort around the automation that occurred through these jobs, and we were able to test through automated testing. The results were controls that addressed the client’s customer contractual obligations and were testable in an automated control test, which significantly decreased workload on the client’s resources.
Simplify Your SOC Audit Process with Expert Guidance from LBMC
Struggling with SOC audit complexities? At LBMC, we help organizations move from confusion to compliance with practical solutions tailored to your environment. Reach out to see how our experience can simplify your audit process and strengthen your controls before the next deadline hits.
Content provided by Andrew Stansfield, Manager, Akshaya Kulandai Samy, Manager, and Jessie Sliger, Senior Consultant, LBMC Cybersecurity. Contact them at andrew.stansfield@lbmc.com, Akshaya.Samy@lbmc.com, and Jessie.Sliger@lbmc.com.