Learn about SOC 2 key control areas including access, change management, incident response, vendor risk, encryption, remote work, and more through the Frequently Asked Questions (FAQs) below. Please schedule a consultation if you are looking for a SOC 2 Readiness Partner or would like to discuss a customized solution for your organization.
Table of Contents
What do SOC 2 auditors specifically look for in logical access controls?
Logical access controls are the most tested and most exception-prone area in SOC 2 examinations. Auditors verify six things: that access is granted through a documented, approved provisioning process; that access is revoked promptly when employees terminate, typically within twenty-four hours for high-risk systems; that user access reviews are conducted quarterly for privileged access and semi-annually for standard access, and are documented; that multi-factor authentication (MFA) is enforced on all in-scope systems; that the principle of least privilege is applied, users have only the access their role requires; and that privileged accounts are inventoried and reviewed separately from standard accounts. The most common exceptions are terminated employees retaining access beyond acceptable timeframes, access reviews not completed on schedule, and MFA not enforced on all in-scope systems.
What does SOC 2 require for change management?
SOC 2 change management controls require that changes to in-scope systems, application code, infrastructure configuration, databases, and security settings, follow a documented, authorized process before being deployed to production. Auditors verify that a formal change request exists for each change; that it was tested in a non-production environment; that it was reviewed and approved by someone separate from the implementer; that emergency changes follow an expedited but still documented process; and that change records are maintained for the full observation period. The most common findings are changes deployed directly to production without an approved change record, absence of separation between developer and approver, and emergency changes made without documentation.
What does SOC 2 require for incident response?
SOC 2 incident response requirements include a written plan defining what constitutes a security incident, identifying roles and responsibilities, and documenting detection, escalation, communication, and notification procedures; evidence of testing, typically an annual tabletop exercise with a documented outcome; records of actual incidents handled during the observation period, including response timeline, actions taken, and resolution; and a post-incident review process capturing lessons learned. The most common findings are plans that exist on paper but have never been tested, no records showing who was notified and when during actual incidents, and gaps between what the plan describes and what logs show actually happened.
What does SOC 2 require for vendor management?
SOC 2 vendor management requires a documented inventory of in-scope sub-processors, third-party vendors whose services affect the security of customer data. For each sub-processor, organizations must conduct a risk assessment prior to onboarding and annually thereafter. Vendor contracts must include data handling obligations, breach notification timelines, and the right to review compliance documentation. Auditors verify the inventory, review sample assessments, and test whether assessments were completed on schedule. The most common findings are high-risk sub-processors onboarded without a prior assessment, annual assessments not completed on time, and vendor contracts lacking specific security provisions.
What does SOC 2 require for physical security controls?
Physical security is an explicit part of SOC 2’s Security criterion and is tested in every examination, including organizations using cloud infrastructure exclusively. For organizations with their own data centers, auditors verify physical access controls: key card systems, biometric readers, visitor logs, and surveillance. For organizations using cloud providers via the carve-out method, the expectation is that the organization has reviewed the physical security posture of those facilities through the cloud provider’s own SOC 2 Report. For office environments, auditors may review workstation access controls, clean desk policies, and physical media handling. Cloud-only organizations are not exempt, they must document their reliance on cloud provider physical controls and demonstrate they have evaluated them.
What does SOC 2 require for background checks?
SOC 2 Personnel Security controls require organizations to conduct background checks on employees with access to customer data and in-scope systems as part of the hiring process. Auditors verify that a background check policy exists defining which roles require checks; that background checks were conducted for new employees onboarded during the observation period; and that records of completed checks are maintained. The policy must also address contractors and third parties with significant system access. The most common finding is that background check requirements exist in a written policy but records of actual checks during the observation period are incomplete or unavailable. Auditors verify completion, not the contents of the checks.
What does SOC 2 require for security awareness training?
SOC 2 requires annual security awareness training for all employees with access to in-scope systems or customer data, covering phishing awareness, password security, acceptable use, incident reporting procedures, and data handling obligations. Auditors verify that the training program was completed within the past twelve months; that completion records exist for every employee in scope; and that new employees received training within thirty days of joining. The most common findings are employees who did not complete training within the required period, incomplete records lacking completion dates, and new employees going months without training because onboarding was not connected to the training program.
What is the difference between a SOC 2 security policy and a security procedure?
A security policy defines the organization’s intention and requirements, the what and why: management’s commitment, the rule to be followed, and who is responsible. A procedure defines the how, the step-by-step operational instructions for implementing the policy. SOC 2 requires both. A policy without a procedure leaves employees without operational guidance. A procedure without a policy lacks management authorization and governance context. Auditors test whether both exist, whether they are current, reviewed within the past year, and whether employees can demonstrate they follow them. Organizations that document policies but never write procedures routinely generate findings during fieldwork.
What does SOC 2 require for encryption?
SOC 2 does not prescribe specific encryption algorithms, it requires that sensitive data be appropriately protected, and auditors assess whether the methods in place are suitable for the risk. In practice, auditors look for AES-256 for data at rest and TLS 1.2 or higher, with TLS 1.3 preferred, for data in transit. For key management, auditors verify that encryption keys are stored separately from the data they protect, that access to keys is restricted to authorized personnel, and that key rotation is documented and followed. For legacy systems that cannot support current standards, organizations must document compensating controls and a remediation plan. Evidence includes configuration screenshots, TLS configuration records, and key management documentation.
Is penetration testing required for SOC 2?
Penetration testing is not explicitly mandated by the AICPA Trust Services Criteria, but it is strongly recommended and many auditors suggest it as part of examination preparation. Penetration testing identifies exploitable weaknesses in systems before the formal examination begins, strengthening the control environment and reducing the likelihood of security-related findings during the audit. It frequently surfaces issues in network security, application security, and access controls that gap assessments alone do not identify. A thorough gap assessment at the outset is the best way to determine whether the auditor will recommend penetration testing before committing the budget.
How does SOC 2 apply to remote workforce endpoint and network security?
Every device used to access in-scope systems is a candidate for SOC 2 examination scope, and all remote access must route through mandatory VPN or Zero Trust Network Access (ZTNA), not optional use.
For endpoints, auditors look for evidence that the organization has inventoried in-scope devices, applied consistent security configurations, and enforced controls, MFA, disk encryption, screen lock, and current antivirus, across the full endpoint population. Mobile Device Management (MDM) platforms are the primary tool for demonstrating this at scale: MDM-generated compliance reports showing which devices meet configuration requirements are the evidence auditors look for. Organizations without MDM enforcement on remote endpoints frequently cannot produce the evidence needed to demonstrate consistent endpoint control operation during the observation period.
For network security, home and remote networks are outside the organization’s direct control. The compensating approach auditors accept is requiring all remote access to in-scope systems to pass through a VPN or ZTNA solution, ensuring traffic enters the in-scope environment through a controlled, authenticated, and logged pathway. Auditors verify that VPN or ZTNA is enforced, not optional, and that logs of remote access sessions are maintained and reviewed. The most common findings in this area are endpoints not enrolled in MDM and VPN use that is recommended rather than enforced.
How does SOC 2 apply to remote workforce access controls?
Access provisioning and de-provisioning controls are tested the same way regardless of whether the workforce is remote or office-based. Distributed teams that rely on informal channels, Slack messages or email threads, rather than a formal ticketing system frequently cannot produce the traceable documentation auditors require. All access provisioning and de-provisioning requests must flow through a system that generates a dated, attributable record. The most common finding in this area is access changes initiated outside the formal ticketing system, leaving no audit-ready trail for fieldwork.
What do SOC 2 remote work policies and security awareness training require?
SOC 2 requires documented evidence that employees have acknowledged security policies specifically addressing remote work obligations, and that training completion records cover the full workforce regardless of location.
Auditors verify that security policies explicitly address remote-specific obligations: use of approved devices, prohibition of accessing in-scope systems from unsecured public networks without VPN, physical security of the work environment, and clean desk and screen requirements when working from home. Auditors sample policy acknowledgment records and verify that remote-specific provisions are explicitly included in what employees have signed, not implied by general policy language.
Security awareness training completion records must cover the entire employee population. Distributed teams that rely on self-reported completion or calendar invitations rather than a centralized training platform with exportable completion records routinely generate exceptions. The most common findings are policy acknowledgment records missing remote-specific provisions and training records that cannot be exported by employee with completion dates.
Explore Blogs, Webinars and other Resources
Trusted by Reputed Companies
Accreditations and Associations
* Disclaimer: This list of accreditations is held by our team of employees and consultants.
What Our Clients Say
We used databrackets (formerly EHR 2.0) in our small medical practice for our risk analysis assessment to be in compliance with meaningful use. Their response was fast, the final report is detailed but simple and easy to follow. They were always available to answer our questions.
E. Compres
Pulmonary and Sleep Center of the Valley
I never miss the opportunity to learn something new …that’s why I am always registering to all free seminars offered on the web. databrackets (formerly EHR 2.0) happened to be the friendliest, comprehensive and up-to- date source of HIPAA Privacy and Security updates.
Alexandra V.
Community Healthcare Network
Today’s presentation was great! Thank you for sending the slides. My only feedback is that it would be fabulous to have the slides ahead of time so I could print them and take notes on the slides.Thanks for your time and knowledge today!
T.B., PM
Community Health Network
Particularly interesting was the flow chart on Administrative Simplification. I utilize all of the Security subcategories you list under the Security tile and appreciate knowing that I am hitting all of the relevant topics during my employee training.
Jessica B.
JD, CHC
I have re-worked our original risk assessment….We are using databrackets' (formerly EHR 2.0) Meaningful Use Security Risk Analysis Toolkit and it meets our needs. It was easy to use and I believe that it very beneficial to our meeting meaningful use.
Bill Curtis
Neurosurgical Associates Of Texarkana, TX
Information (webinars) presented by databrackets (formerly EHR 2.0) highlights some of today’s most demanding healthcare topics. The webinars help to direct those operating in today’s rapidly changing environment in the right direction.
Candace M.
Privacy and Security Officer, Springhill Medical Center
Our Growing List of Credentials
0
+
Assessments
0
+
Clients
0
+
Assessment Libraries
0
+
Years of Experience
0
+
No. of Staff Trained
0
+
HIPAA
0
+
SOC 2 Readiness
0
+
Pen Testing
0
+
ISO 27001 Certifications
0
+
Dollars Saved in Compliance Penalties