This article brings together common customer questions and practical answers based on typical Secureframe workflows, compliance situations and unique tech stacks.

It is meant as quick reference material for day-to-day use of the product.

Readiness and planning

SOC 2 Readiness Assessment [2021] vs. SOC 2 Readiness Assessment

• The updated readiness assessment has more granular tests than the 2021 report. This increases the total number of tests and may reduce a customer’s completion percentage. The old report must be disabled to turn on the new version, which may require re-disabling tests that were previously disabled in the 2021 version.

What is the typical preparation time required for SOC 2 compliance?

• The typical preparation time for SOC 2 compliance can vary, but here’s a general breakdown:

  🕐 Typical Preparation Timeline

  Without automation: 6 to 12 months

  With automation tools like Secureframe: As little as a few weeks to 3 months

  📌 Factors That Affect the Timeline

  Existing Security Posture: If your organization already follows best practices (e.g., access control, data encryption, vendor risk management), you’ll move faster.

  Size and Complexity: Larger or more complex organizations with multiple products, vendors, and teams often take longer.

  Trust Services Criteria Chosen: The more criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) you include, the more work is required.

  Level of Internal Readiness: Having documentation, policies, and processes in place speeds things up.

  Type of Report:

  SOC 2 Type I (snapshot in time): Quicker—can be ready in weeks.

  SOC 2 Type II (over a period, usually 3–12 months): Takes longer due to monitoring requirements.

  🚀 With Secureframe

  Customers using Secureframe often:

  Prepare for a SOC 2 Type I audit in 4–6 weeks

  Begin a SOC 2 Type II audit within 3 months, depending on their audit window and readiness

SOC 2 Type 1

Do clients have to pursue SOC 2 Type 1 before pursuing a SOC 2 Type 2?

• Clients do not need to pursue SOC 2 Type 1 before SOC 2 Type 2, but Type 1 is often recommended as a starting point to get familiar with the audit process. A Type 2 audit typically requires more work, but skipping Type 1 can be done if the client is prepared.

How do I scope a SOC 2 Type 1 vs Type 2 report?

• Indicate during SOC 2 scoping whether you're pursuing a Type 1 (point-in-time) or Type 2 (observation period) report. For Type 2, include the review period.

How much time does it take a single person or team to interface or interact with an auditor for a SOC2, Type 1?

• There isn’t much time spent back and forth since Secureframe grants auditors access to the platform. They may reach out if they need extra evidence or have questions. Most time is spent preparing Secureframe to be 100%.

If vulnerability tickets were not resolved within SLA during a SOC 2 Type II audit period, can a company avoid a finding?

• If vulnerabilities were not remediated within the defined SLA during the audit observation period, it is generally difficult to fully avoid a finding. SOC 2 Type II audits evaluate whether controls operated effectively during the review period. However, findings are not uncommon and do not automatically mean audit failure. Organizations can often demonstrate remediation steps, process improvements, and strengthened controls to show the issue has been addressed moving forward. Auditors may include this context in the report.

Is CAPTCHA a requirement for SOC2 Type 1 compliance?

• No — CAPTCHA is not a requirement for SOC 2 Type I.

  SOC 2 requirements are principles-based and focus on the Trust Services Criteria (TSC) — security, availability, processing integrity, confidentiality, and privacy. Controls are chosen by the organization and then evaluated by the auditor.

  What is required: You must show that you have reasonable controls in place to prevent unauthorized access (e.g., authentication, access controls, monitoring, MFA).

  What is not required: Specific technologies like CAPTCHA are not mandated. An organization could use CAPTCHA as one of many methods to reduce automated attacks (like credential stuffing or brute force login attempts), but it’s entirely optional.

Is SOC 1 point in time test like SOC 2 type 1 or observation window like SOC 2 type 2?

• SOC 1 operates similarly to SOC 2, with both Type 1 (point in time) and Type 2 (observation window) options.

Our company recently acquired another business, but the two entities are still operating separately with different systems (e.g., Office365, Gusto) and tax IDs. How should we structure compliance for both moving forward? The acquired company previously obtained a SOC 2 Type I.

• You have a couple of options, depending on how closely aligned the two entities are operationally:

  Separate SOC 2 Reports (Short-Term Option)
  Since the two business units—let’s call them BlueDrive and Nexfi—are still largely operating independently, it may make sense to maintain separate SOC 2 reports for now. This allows each to maintain its own policies, systems, and environments while staying compliant.

  Unified SOC 2 Report (Long-Term Option)
  Over time, you can begin aligning policies, procedures, and systems across both BlueDrive and Nexfi. This may include standardizing security policies, onboarding practices, access control systems, and vendor management workflows. Once sufficiently integrated, you can pursue a single consolidated SOC 2 report that covers both business units under a shared compliance framework.

  This phased approach allows you to stay compliant now while building toward a unified and streamlined compliance structure in the future.

Regarding the Azure diagnostic log retention (365 days) test in Secureframe. Is 365-day retention period is explicitly required by SOC 2 Type II, or if it’s something we recommend based on industry standards.

• This is more based on industry standard.

Should I be at 100% passing prior to a SOC 2, Type II observation window?

• You should aim to be as close to 100% passing as reasonably possible before entering a SOC 2 Type II observation window, with a focus on implementing the underlying processes for any remaining upload-based tests.

  It’s normal for certain upload-based tests to remain incomplete until evidence naturally falls within the observation period. Once the required processes are in place, the auditor will typically specify which evidence they want to review and the applicable timeframe. At that point, it’s best to wait for that guidance before uploading documentation to ensure it’s in-scope and aligned with auditor expectations.

  Additional context to keep in mind:

  Upload-based tests are intended to validate that a control is operating over time, not that evidence was uploaded early.

  Some evidence cannot exist until the observation window is underway, and auditors expect this.

  Secureframe can still be used proactively to track readiness and identify gaps before the observation period begins.

  Your CSM can help determine which items should be completed in advance versus which are expected to be finalized during the audit.

  This approach helps ensure audit readiness while avoiding unnecessary rework or misaligned evidence submissions.

We have a customer that wants Secureframe to post and share their SOC 2, Type 1 on Linkedin or other Social Media. Do we do that? If yes, who would be the right person to facilitate that post?

• Yes, Secureframe can repost compliance announcements on platforms like LinkedIn. Contact Anna Fitzgerald to facilitate the post.

What is the difference between a SOC 2 Type 1 and Type 2?

• Type 1 is a point-in-time assessment that verifies the processes and controls implemented to protect customer data. Type 2 takes place over a period (usually 3-12 months) and assesses whether those processes and controls have been operating effectively over that time period.

What is the difference between SOC 2 Type 1 and Type 2?

• Type 1 evaluates compliance at a single point in time, while Type 2 assesses compliance over a period of time.

What is the minimum policies you expect employees or personnel to accept for SOC 2, Type 1?

• At a minimum, employees must accept the Code of Conduct and Acceptable Use policies. Additional policies can be assigned to relevant groups using the platform's 'groups' feature.

SOC 2 Type 2

Do Secureframe's policy templates include SLAs for fixing vulnerabilities, and is this required for SOC 2 Type 2?

• Secureframe's policy templates are intentionally kept high-level on SLAs since requirements vary by organization. Some SLAs are included where standard practice dictates (for example, User Access Reviews are set to quarterly in the Access Control Policy). For Vulnerability & Patch Management, the policy focuses on prioritizing critical and high-risk vulnerabilities first rather than prescribing specific remediation timeframes. Customers are encouraged to add SLAs that reflect their own risk tolerance and operational requirements.

How should I upload evidence in Secureframe for a type 2 soc 2 audit?

• Regardless of the type of framework you are working on, you have a few options when it comes to uploading evidence in Secureframe.

  For Upload Tests: You can manually upload files as evidence. This is useful for covering any gaps in automated evidence collection.

  Integration Test Evidence: Once you have connected as many integrations as possible, Secureframe will automatically collect evidence. This is the most efficient approach for automating compliance so our recommendation is to integrate as many as possible.

  Platform Evidence: For some test like Policy Acknowledgement, Security Awareness Training and more, these are automatically captured in platform as your users complete the relevant test.

  Additionally, in some cases you can manually upload evidence into the Data Room. Ex, you have already collected Background checks for the year, you could bulk upload and link to relevant test.

  If evidence is uploaded on a single test, and that test is associated to multiple frameworks, it will satisfy all.

Regarding Data Retention and Disposal policy, is obtaining certificates of destruction from an outside vendor for individual hard drives something auditors are likely to be looking for in a future SOC2, Type 2 audit?

• The device needs to be sanitized when it’s no longer in control of the company or contains sensitive information. Otherwise, they can just format it and give it to a new employee. See this article on NIST: NIST 800-88 Media Sanitization

SOC 2 general

A vendor does not have a compliance report (e.g., SOC 2, ISO, PCI). What do we upload instead?

• Provide evidence showing that due diligence was performed on the vendor, such as a completed security questionnaire.

Are all pre-populated SOC 2 policies within the platform applicable to our organization and all individuals?

• Not all sections of every policy apply to everyone. Customers may combine policies or omit certain sections based on their needs, but they should ensure they document why certain policies don’t apply. Every policy maps to a related test, so if a policy is not published, include a justification.

Are container scans required for SOC 2?

• No, container scans are not a strict requirement for SOC 2. However, if you’re not conducting other internal or external vulnerability scans, container scans may be necessary, especially if you use containers. If you’re performing other scans, container scans may not be required.

Are mobile devices/tablets/iPhones in scope for SOC 2 or just laptops and desktops?

• Typically, unless mobile phones are corporate mobile phones, only laptops and desktops are in scope. This can vary depending on the auditor.

Are performance reviews required for company owners or founders under SOC 2?

• No. SOC 2 does not require performance reviews for company owners or founders. Since there is no one to administer the review in these cases, it should not be considered a requirement. If an auditor requests this, you can push back and clarify that performance reviews only apply to employees where a manager or supervisor can reasonably conduct the review.

Are there any significants differences between controls for SOC 2 and PCI? Specifically the User Access Reviews test.

• Yes, for this particular test the key difference is due to the purpose and scope of each framework:

  PCI DSS 4.0 is a strict, control-specific framework focused on the Cardholder Data Environment (CDE). It requires detailed reviews of both user and service account privileges to ensure only necessary access to payment systems.

  SOC 2 is principles-based and covers broader systems tied to security, availability, and confidentiality. It emphasizes that system owners conduct regular access reviews for production systems, with a focus on overall governance and accountability—not just sensitive data access.

  One of the key differences here is service account reviews must be included as well for PCI.

Are there any specific tests related to databases for SOC2 compliance?

• Databases are typically covered through the following controls, depending on use and data sensitivity:

  Access controls: AC 01, AC 02, AC 03, AC 06, AC 07

  Vulnerability management: AV 01, AV 02

  Change management: CM 01, CM 02, CM 03

  For specific guidance on how these controls apply to your environment, please reach out to your Customer Success Manager.

Can a company "inherit" certifications from vendors? For example, if company A incorporates the technology of a SOC2 compliant company into our software product, does that make company A compliant?

• No, they wouldn't be SOC 2 compliant. They would need to go through their own audit to get a SOC 2 report for their company. If they adopt configurations from SOC 2 compliant companies, they would be more ready for their audit, but they still need a review of their own company to be awarded a report. SOC 2 has a report as the final deliverable, and there is no inheritance.

Can a contractor use a personal GitHub account for company code during a SOC 2 audit?

• It is strongly recommended to use a company-owned GitHub or Bitbucket account to ensure proper ownership, access control, and auditability. If a contractor must use a personal account, they should be treated as in-scope personnel and must follow company security requirements, including MFA, encryption, device security controls, and policy acceptance. If the contractor works through a third-party company, they may also be managed as a vendor.

Can a SOC 2 penetration test be performed in a UAT (non-production) environment instead of production?

• Yes — as long as the UAT environment accurately mirrors production in security-relevant ways, including:

  Same infrastructure configuration
  Same access controls and authentication model
  Same network architecture and connectivity
  Same security tooling (EDR, logging, monitoring)
  Same deployment and patching practices

  This is common for organizations that must avoid testing on live customer data in production.

Can having an SOC2 for a vendor affect the risk score, and is it possible to downgrade it as a result?

• Yes, having an SOC 2 or similar security report for a vendor can influence how you assess their risk level. While Secureframe's Vendor Risk Score is initially suggested based on a general assessment of the vendor type, you can manually adjust the score based on any additional due diligence you've completed—such as collecting SOC 2 reports, security questionnaires, or other assurances.

  Auditors are not focused on the overall distribution of vendor risk scores (e.g., how many vendors are marked high vs. low risk). Instead, they care whether you’ve identified high-risk vendors and performed appropriate due diligence. This includes gathering evidence like SOC 2 reports, documenting any risks, and clearly showing that vendor assessments have taken place.

  Currently, Secureframe does not automatically adjust a vendor’s risk score based on uploaded mitigations like SOC 2 reports, but you are encouraged to factor those into your manual assessment and scoring.

Can Secureframe support a SOC 1 as well as our SOC 2?

• Secureframe can support SOC 1 IT general controls (ITGC) as they map directly to SOC 2. Other SOC 1 controls will need to be handled outside Secureframe until custom controls become available.

Can Semgrep Community Edition (CE) be used as an open-source SAST tool, and is it sufficient for SOC 2 requirements?

• Yes — Semgrep CE can be used as an open-source SAST tool and is generally sufficient for SOC 2 requirements.

Customer doesn't have customers yet, so should they do SOC 2 compliance for dev or spin up prod environment?

• The audit must be done on the production environment, even if it doesn't have live customer data. Auditors would need to ensure production mirrors dev.

Customer has a US and UK entity (or Canada), which both fall under the group entity. Is one SOC 2 report sufficient or is one certification/report per entity required?

• If the infrastructure and personnel supporting both entities are the same, one certification may suffice. However, ensure that all personnel across both entities are included in the scope of your audit and update policies accordingly.

Do the SOC2 controls provided by Secureframe align with the official AICPA SOC2 guidelines?

• Yes—Secureframe’s SOC 2 controls are designed to fully align with the official AICPA SOC 2 Trust Services Criteria.

Do you happen to know if there is a certain type of product needed on Heroku (e.g., hobby, production, private, shield) for SOC2?

• For SOC 2, it’s important to ensure that your environment on Heroku has the same control and insight as other cloud providers like AWS, GCP, or Azure. Heroku’s configuration should meet access control, logging, monitoring, and alerting requirements.

Do you need a company website to pass SOC 2?

• The marketing website does not necessarily have to be SOC 2 compliant unless it processes customer data. If there's no website, draft a security commitments page and terms of service to share with customers.

Does a SOC 2 with Secureframe comply with SSAE 18?

• Yes, all SOC 2 reports must be done under the AICPA’s SSAE 18 standard, so if they get a SOC 2, it was done under that standard.

Does Secureframe provide a sample NDA that customers can use for sharing their SOC 2 report (e.g., through Trust Center)?

• Secureframe does not provide a sample NDA template for sharing SOC 2 reports. We recommend customers consult with their legal counsel to draft an NDA that aligns with their business needs and legal requirements.

  Tip: Some customers use their own standard NDA or reference Secureframe’s NDA (if applicable) as a starting point, but it's always best to have legal review the content before sharing sensitive reports like a SOC 2.

Does SOC 2 specify what level of security training is required?

• No, it is up to your discretion. The auditors won’t necessarily question the depth of that training.

Does working with a company that has SOC 2 compliance affect a contractor's scope?

• While third-party firms that hire contractors are responsible for ensuring their compliance with controls, the company undergoing the audit retains ultimate accountability for all personnel's adherence to relevant controls.

For SOC 2, how many job descriptions do I need to upload?

• For SOC 2, you only need to upload job descriptions for roles that are responsible for the Trust Services Criteria in your scope — such as security, availability, processing integrity, confidentiality, and privacy.

  If you are only scoped to the security criteria, make sure the role(s) accountable for security have job descriptions that clearly outline those responsibilities.

  Auditors may also select additional roles during the audit to confirm job descriptions exist across the organization, so while you only upload the key ones, you should still maintain job descriptions for all positions internally.

  Example for a small team:
  If your company has 8 employees and you are the sole compliance person, you would upload your job description (since you are responsible for the scoped criteria) and be prepared to provide the others if requested by the auditor.

How can a company identify missing evidence when adding a new framework (example SOC 2) after already being compliant with another framework (ex NIST)?

• When adding a new framework after completing another (for example, moving from SOC 2 to NIST, ISO, HIPAA, or any other framework), you can use the platform’s framework and filtering tools to quickly identify any remaining gaps.

  Start by using the framework filter to isolate the framework you’re working on so you only see controls and tests specific to that framework. Then use the quick filters to sort by failing or not-passing tests to highlight areas that still need evidence.

  You can also review the “Last Uploaded” column to see when — or if — evidence has been uploaded for each test. This helps identify controls that are missing documentation or may need updated evidence.

  These filters work across all supported frameworks and provide a clear way to identify what additional evidence is needed when expanding compliance coverage.

How do I scope for SOC 2 compliance?

• For SOC 2 scoping, determine if you are pursuing a Type 1 or Type 2 report. Select Trust Services Criteria—Security is required; Confidentiality, Availability, Processing Integrity, and Privacy are optional. Disable unneeded sections in Secureframe. Clarify how you manage vulnerabilities (e.g., regular scans or pen testing).

How does a customer know if availability should be in the scope of their SOC 2 audit?

• If the company needs to ensure that their system is always available for users (e.g., payroll management services), availability should be in scope for the SOC 2 audit.

How does a customer know if processing integrity should be in the scope of their SOC 2 audit?

• Companies processing a lot of data or with many integrations (like Secureframe) should include processing integrity in their SOC 2 audit scope.

How does Secureframe accelerate SOC 2 compliance?

• Secureframe automates audits, integrates with security tools, and provides pre-mapped controls and tests.

How many CIS IG1 controls overlap with SOC 2 requirements?

• There is no official, one-size-fits-all number of CIS Controls IG1 that overlap with SOC 2, because it depends on how the SOC 2 Trust Services Criteria (TSCs) are implemented and how your auditor interprets them. However, we can give a general idea based on mappings done by security experts and frameworks like Secure Control Framework (SCF), AuditScripts, and Center for Internet Security.

  Quick Breakdown:

  CIS IG1 (Implementation Group 1) includes 56 Safeguards (formerly called Sub-Controls) aimed at essential cyber hygiene.

  SOC 2 is based on the Trust Services Criteria: Security (required), and optionally Availability, Confidentiality, Processing Integrity, and Privacy.

  General Estimate:

  Out of the 56 CIS IG1 controls, about 35–45 of them typically overlap with SOC 2 Security criteria (Common Criteria + some related to Confidentiality and Availability, if included).

  Types of Overlapping Areas:

  Access Control – Both frameworks require controls for managing user access, least privilege, and account monitoring.

  Asset Management – SOC 2 expects you to know what systems and data you’re protecting; CIS requires inventory tracking.

  Vulnerability Management – Both require regular vulnerability scanning and patching.

  Audit Logging & Monitoring – Required by both for detecting and responding to threats.

  Security Awareness & Training – Required by CIS IG1 and implied in SOC 2's control environment and risk mitigation practices.

  Incident Response – Both require plans and response procedures for security events.

  Summary:

  🔁 ~60–80% of CIS IG1 controls have some degree of overlap with SOC 2 requirements.

  ✅ Implementing CIS IG1 gives you a strong foundation for SOC 2 readiness.

  📋 You still need to map each control to your SOC 2 auditor's expectations, as SOC 2 is principles-based, not prescriptive.

If a company is not able to get a vendor's SOC 2 report, would that impact the Company's SOC 2 report?

• Vendor attestation report reviews are key to the SOC 2 process. If the vendor’s SOC 2 or ISO 27001 certification is unavailable, the company is expected to audit the vendor via a security questionnaire. We have a template security questionnaire available in the data room’s templates folder. If the vendor doesn’t complete the questionnaire or lacks certifications, it will show as an exception on the SOC 2 report.

If a company is working with a vendor who is high risk and they don't have a security certification (like SOC 2), would that cause the auditor to mark up their report and potentially affect their compliance?

• Yes, unless additional due diligence is performed. The company is expected to audit the vendor or review compliance reports. If they do not, it will be marked as an exception on their report.

If a company's products don't handle any customer data, which employees would be in-scope for a SOC 2 audit?

• If the company's products don't handle any customer data, the group of employees in-scope for SOC 2 will be smaller. Typically, employees with access to and responsibility for the systems supporting the products would be in-scope, including:

  Engineering
  DevOps
  IT
  Security
  Management overseeing the audit

  Employees who don't have access to the systems (e.g., HR, Marketing) would generally be considered out of scope for the audit.

If a customer has already started SOC 2, when should they consider starting ISO? What's the level of additional work required? How should they time their audits?

• If a customer is conducting their Type I audit and also planning a Type II, we recommend timing the Stage 1 and 2 ISO audits within 3 months of the end of the Type II audit so they can use the same evidence for overlapping controls. The additional work will include adopting new policies, performing an internal audit (which takes about 2-4 weeks), and conducting an annual management review meeting for the ISMS.

If a subsidiary of a parent company is getting a SOC 2, which name should be used in the platform? The subsidiary's or the parent's?

• Use the name of the entity that is getting the SOC 2, i.e., the subsidiary if they are the ones undergoing the audit.

If my company uses a work email provider (like Google Workspace or Microsoft 365), do we need to include it for SOC 2 compliance?

• Yes. Your company’s email provider is considered an in-scope system for SOC 2 because it’s a core communication tool and entry point to sensitive systems and data. While you don’t necessarily have to integrate it into Secureframe, doing so helps automate evidence collection (e.g., user lists, MFA enforcement, offboarding). If you choose not to integrate, you’ll need to provide this evidence manually.

If we're already SOC 2 compliant and require employees to acknowledge all policies, do we also need everyone to accept our procedures to meet TX-RAMP requirements?

• No, you don’t need to have employees acknowledge every procedure to meet TX-RAMP requirements — especially if you’re already SOC 2 compliant and have acknowledgment in place for key policies like Acceptable Use, Information Security, and Confidentiality.

  TX-RAMP focuses on ensuring staff:

  Receive security awareness training

  Acknowledge critical policies

  Are aware of their security responsibilities

  Your current SOC 2 practices likely satisfy TX-RAMP in this area, and expanding acknowledgment beyond policies isn't necessary unless your risk assessment calls for it.

  As it relates to Secureframe platform, an Admin will need to review each policy, make sure the appropriate groups are assigned, to ensure the right policies are assigned to the right users.

Is a Data Loss Prevention (DLP) solution required for SOC 2 compliance?

• DLP is not a hard SOC 2 requirement, but it’s recommended for a stronger security posture. DLP helps monitor and prevent unauthorized changes to sensitive files and data. Tools like Nightfall and Google’s native solutions are examples of DLP.

Is a network security policy required for SOC 2 compliance?

• Yes, a network security policy is required for SOC 2 compliance—though it's not always named explicitly as such.

  SOC 2 requires controls aligned with the Trust Services Criteria, particularly under the Security (Common Criteria) category. These include:

  Logical and physical access controls

  System operations and change management

  Risk mitigation

  Network protections such as firewalls, intrusion detection/prevention, and secure configurations

  A network security policy helps demonstrate that your organization:

  Defines how networks are protected (e.g., firewalls, VPNs, segmentation)

  Enforces secure access controls and monitoring

  Maintains secure configurations for routers, switches, and other infrastructure

  While SOC 2 doesn't dictate specific policy titles, having a documented and enforced network security policy supports multiple required controls and is considered a best practice (and often expected by auditors).

Is a pen test required for SOC 2?

• Generally, yes. Pen tests are required for SOC 2 Type 2 unless the environment is closed and robust vulnerability scanning is in place.

Is a VPN required for SOC 2?

• SOC 2 does not require a VPN, but the trend is moving towards Zero Trust Networking. This approach eliminates the need for a VPN by securing user access based on authentication and device compliance rather than relying solely on a VPN.

Is cyber insurance a hard requirement for SOC 2?

• Not a hard requirement, but definitely a nice-to-have.

Is Hard Drive (HD) encryption required for SOC 2?

• Yes, but if you don't plan to implement it, you should have compensating controls and document that hard drive encryption is not enforced in the risk register.

Is it okay to use a SOC 2 or SOC 3 report from over a year ago if no newer one is available?

• It depends. Ideally, the report should be within 12 months. If the latest available report is more than a year old (e.g., Rippling’s SOC 3 from July 2022 – June 2023), you may need to reach out to the vendor for a more recent report or supplementary documentation.

Is it possible to have no vendors in a SOC 2 environment?

• Technically yes, but it's extremely rare. Most organizations rely on at least a few third-party services — such as cloud infrastructure (e.g., AWS), email providers, communication tools, or HR platforms — even if they don’t think of them as “vendors.” SOC 2 expects you to identify any third parties that impact your systems or data, even if they're free tools or background utilities.

Is it possible to search through specific requirements within SOC 2 controls, rather than just the controls themselves?

• Yes. You can use the Frameworks page to view each control requirement and expand the requirement to see the related or mapped controls. You can also use the Global Search to look up specific controls or requirements across your entire instance.

Is PIPEDA the Canadian equivalent of SOC 2? Do we support it?

• No — PIPEDA (Personal Information Protection and Electronic Documents Act) is a privacy law in Canada and is more comparable to GDPR than to SOC 2. While SOC 2 focuses on the security and availability of systems, PIPEDA governs how organizations collect, use, and disclose personal information.

Is screen lock a hard requirement for SOC 2?

• No, it’s a best practice, but not a hard requirement for SOC 2.

Is SOC 2 about employee information or customer information?

• SOC 2 focuses on customer information. However, employee information is relevant if the employee has access to customer data.

Is the Data Protection Impact Assessment for CCPA-CPRA the same as Vendor Compliance Reports for SOC2?

• No, the Data Protection Impact Assessment (DPIA) for CCPA-CPRA and Vendor Compliance Reports for SOC 2 are not the same, though they both relate to privacy and security.

  A Data Protection Impact Assessment (DPIA) is a process used to identify and minimize privacy risks when processing personal data. It helps organizations understand how their data processing activities could affect individuals' privacy rights and ensures they take appropriate measures to protect personal data. DPIAs are especially important when processing activities are likely to result in a high risk to individuals' rights and freedoms, such as when using new technologies or processing sensitive data. The assessment includes evaluating the necessity and proportionality of the processing, identifying risks, and implementing measures to mitigate those risks.

Is there a way for a customer to bypass specific controls for SOC 2 in our system if they are meeting the test requirements outside of Secureframe?

• Yes, they can upload evidence directly to the test or disable the test and cite that manual evidence has been added to the data room.

Is vulnerability management included in SOC 2 scoping?

• Yes, indicate whether you perform scans or penetration testing and what tools you use. This affects test enablement.

Our company is fully remote and does not use traditional firewalls. Will this impact our ability to meet SOC 2 firewall-related controls or policies?

• Not necessarily. SOC 2 requires that you control and monitor network traffic and security, but it does not mandate the use of traditional firewalls. If you use alternative mechanisms—such as security groups, endpoint protection, or cloud-based network security controls—you can still meet SOC 2 requirements. The key is to document your approach and demonstrate that you are effectively managing and monitoring network access and traffic.

Our pentest was completed within the audit period but is now more than 12 months old relative to the observation period start date. Is it still valid for SOC 2?

• Likely not without consequence — if pentests are a core part of your vulnerability management program, auditors may issue a qualified opinion. Confirm with your auditor whether the pentest needs to remain valid (within 12 months) for the entire audit period, or simply needs to fall within 12 months of the audit end date, as requirements can vary.

Should my contractors be in scope for SOC2?

• Ask: 1) Does the contractor interact with customer data? 2) Do they support the system being audited? 3) If no, does their work directly impact business objectives or customer commitments covered by the audit? For Type 2, all contractors/employees must accept policies and complete security training.

Vendor SOC 2 reports are dated just outside the 12-month lookback window for our audit period. Are they still acceptable?

• Generally yes, but you should gather the reports, review them, and document that review before your audit end date. Auditors will typically accept reports that are slightly outside the window as long as you've reviewed and documented them appropriately.

We have a small team and can't review every change. Is this a requirement for SOC 2 or a recommended best practice?

• It is a best practice. A change management process is required. If independent reviews are not feasible, peer reviews or paired programming are alternatives. Tools like GitHub or Bitbucket can automate review and approval processes. What’s most important is documenting and implementing one process for compliance.

We have contractors on BYOD (bring your own device) who we don't manage. What are our options for SOC 2 compliance, and how much flexibility do auditors typically allow?

• You have a few options depending on how much assurance you want to provide auditors:

  BYOD Policy + Contractor Agreement Acknowledgment (Minimum): Start with a BYOD policy that outlines endpoint security requirements. Secureframe has templated language for this in the Acceptable Use Policy or Asset Management Policy template. Your contractor agreements should reference this policy and include a signed acknowledgment from the contractor.
  Self-Attestation (Moderate): Auditors can accept a periodic self-attestation approach where contractors confirm their device meets requirements, supported by screenshots or a signed declaration. This is a lighter-weight option that many auditors will accept.
  Lightweight Agent or MDM (Stronger): If you want stronger assurance, consider requiring a lightweight endpoint agent or MDM enrollment on contractor devices. This provides verifiable evidence rather than relying on self-reporting.
  Formal Risk Acceptance (Recommended if going lighter): If you take the screenshot or self-attestation approach, pair it with a formal risk acceptance document signed by someone in leadership. This demonstrates to auditors that the gap was a deliberate, documented decision rather than an oversight.

We have international contractors who function like full-time employees but aren't subject to US labor law. Are they in scope for SOC 2, and does our BYOD policy apply to them?

• Yes. For SOC 2 purposes, geography and employment classification don't determine scope. If a contractor has access to in-scope systems or data, they are in scope regardless of where they are located or whether they fall under US labor law. Your BYOD policy and contractor agreements should apply to international contractors the same way they apply to domestic ones. The labor law conversation is separate from the audit scope question.

We might have seasonal employees that work for 1 month, or maybe 6 months, are they in scope for SOC2?

• Assuming they have access to customer data, then yes. The timing matters. If you do a Type 1 audit in February and these folks haven't onboarded yet, they are out of scope. For Type 2, anyone working within the audit period (e.g., Feb-May 30th) is in scope.

We use an AI tool (Claude) to review and approve code pull requests instead of a human approver. Is this acceptable for SOC 2?

• SOC 2 auditors will typically require a human approver for code pull request approvals. If using an AI reviewer is preferred, we'd recommend logging this as a risk and aligning with your auditor directly to confirm whether they will accept it — as it will likely result in an audit finding if not addressed.

We're on-premises and considering a partial migration to AWS to support our SOC 2 certification. We want to stay on Fundamentals — what should we be thinking about?

• A great starting point is reviewing the inventory of AWS tests to identify which systems or processes would need to move to AWS in order to fulfill your SOC 2 controls. A partial migration to AWS can be a cost-effective path for teams on Fundamentals, allowing you to take advantage of native integrations and reduce manual evidence collection — without needing to move your entire tech stack to the cloud.

What are major components that are part of ISO that are not included in SOC 2?

• ISO includes the Information Security Management System (ISMS), which is more in-depth than SOC 2. The ISO audit also includes additional policies and tests (around 20-30 ISO-specific tests). ISO certification lasts 3 years, whereas SOC 2 is a yearly audit.

What are the consequences of not having SOC 2 compliance?

• Organizations may face lost business opportunities, reduced customer trust, and increased security risks.

What are the risks of overlooking vendors during SOC 2 prep?

• Failing to identify vendors may result in:

  Incomplete or inaccurate risk assessments

  Gaps in required vendor due diligence or monitoring

  Audit findings or control failures due to missing expected safeguards

  Even if you have very few vendors, it’s important to document them and evaluate their risk to show the auditor you're following SOC 2 best practices.

What are the rules around Data Residency for SOC 2?

• SOC 2 doesn't have data residency requirements. It focuses solely on data security.

What documentation is required for a Data Processing Agreement to comply with SOC 2 standards?

• If pursuing the General Data Protection Regulation (GDPR), a Data Processing Agreement (DPA) is required. A DPA is a binding agreement between a data controller and a data processor, or a data processor and a data subprocessor. The DPA serves as a key document to ensure that both the data controller and the data processor understand and fulfill their European Union/United Kingdom (EU/UK) personal data protection responsibilities in a manner that is compliant with GDPR requirements. For instance, when an organization (the data controller) outsources EU personal data processing activities to another entity (the data processor). This could include tasks like payroll management, IT services, cloud storage, or marketing services.

  If pursuing SOC 2 Privacy, the organization is required to inform its customers about the privacy safeguards it has in place and how personal data may be disclosed to third parties. While the organization could use a DPA to fulfill this requirement, it may be more appropriate to use alternative methods if a DPA is considered excessive for the organization’s objectives within the SOC 2 Privacy context. For example, the organization could communicate its privacy safeguards and data disclosure practices to third parties through its external-facing Privacy Policy with customer agreement, incorporate privacy clauses in a service agreement, or include references to the Privacy Policy or specific privacy clauses within a Terms of Service agreement.

  If you are attempting to pass the Data Processing Agreement or equivalent test, we recommend you upload the following docs depending on the framework you are working towards.

  If pursuing GDPR, upload template copy of your Data Processing Agreement (DPA).

  If pursuing SOC 2 Privacy, upload evidence of how the organization communicate to customers its privacy safeguards and data disclosure practices to third parties. Example evidence includes any of the following: DPA, Privacy Policy with customer agreement, privacy clauses in a service agreement, or references to the Privacy Policy or specific privacy clauses within a Terms of Service agreement.

What does customer data have to do with SOC 2 scope?

• The scope of a SOC 2 assessment is based primarily on customer data. Anything or anyone in scope handles or has access to customer data.

What does the SOC 2 "system description" test refer to?

• The SOC 2 "System Description" test refers to the requirement to complete a detailed overview of your organization's control environment. This includes your company background, services, IT infrastructure, people, processes, technologies, and implemented controls. It should clearly explain how your organization meets the applicable Trust Services Criteria (e.g., security, availability, processing integrity, confidentiality, and privacy).

  This document is essential to the audit process. Auditors use it to determine the scope of your assessment and it will be included in your final SOC 2 report. It helps auditors evaluate whether your controls are properly designed and operating effectively.

  You should:

  Fill out all sections completely and accurately.

  Pull from your internal policies and procedures as needed.

  Ensure it reflects your current SOC 2 environment.

  If you've completed a SOC 2 audit before, you can reuse your previous system description—just be sure it's up to date.

  Tip: We strongly recommend asking your auditor for a system description template to guide you. Most auditors provide one, and working from their format ensures you’re aligned with their expectations.

What if a company has multiple apps and/or multiple entities? Do they need multiple SOC 2 reports?

• As long as the infrastructure and personnel supporting both systems are the same, then one SOC 2 report is fine for both.

What if the vendor does not have a SOC 2 report?

• If the vendor does not have a SOC 2 report or other security certifications, request that they complete the external vendor questionnaire and upload it to the data room. If no certs or completed questionnaire are available, gather any publicly available information, such as their security page.

What is a company allowed to do/post once they get their SOC 2 report?

• Companies can announce it on any platform of their choice, typically LinkedIn. AICPA has guidelines for using the SOC 2 logo, and the company should refer to the document when posting announcements. They must register with AICPA to use the logo if they haven’t received an unqualified opinion in the last year.

What is considered in scope for SOC 2?

• Any systems or services that hold or transmit customer data. Any personnel (employees or contractors) with access to customer data are also considered in scope.

What is the bare minimum expectation for risks for SOC 2?

• Customers should at least add risks around fraud. Otherwise, they should add any relevant risks for their organization. An auditor would not want to see zero risks, especially if some controls are knowingly not met.

What is the ideal recommended sequence for SOC 2?

• Start with Type 1 first, then immediately begin your Type 2 window once the Type 1 audit is happening.

What is the overlap between SOC 2 & NIST CSF?

• Many SOC 2 controls are part of the NIST CSF, but not all SOC 2 requirements are part of NIST CSF.

What is the overlap between SOC 2 & TX-RAMP?

• TX-RAMP is a condensed version of FedRAMP, and it overlaps with SOC 2 in areas like access controls, change management, risk management, and network security. However, TX-RAMP also includes additional controls specific to Texas or FedRAMP, and the level of effort depends on which TX-RAMP level the organization needs to achieve.

What is the recommended recovery time in the SOC 2 BCDR policy?

• SOC 2 does not prescribe a specific Recovery Time Objective (RTO) or Recovery Point Objective (RPO). Instead, it requires that your organization:

  Defines RTO and RPO values based on each system's business impact and criticality

  Documents these values in your Business Continuity and Disaster Recovery (BCDR) policy

  Tests the BCDR plan to demonstrate your ability to meet the defined recovery objectives

  For organizations new to compliance, a helpful starting point is:

  Objective Best Practice Starting Point
  - [RTO]: 24 hours for critical systems (maximum acceptable downtime)
  - [RPO]: 24 hours for critical data (maximum data loss window)

  Tip: Begin with a business impact assessment to identify critical systems, then assign recovery targets accordingly.

  “Secureframe cannot define RTO/RPO values for your organization. These must be set internally based on business impact.”

What needs to be included in the Privacy Policy to meet SOC 2 requirements?

• SOC 2 requirements for Privacy Policies include: notice, choice, consent, data collection, retention, disposal, access, disclosure to third parties, and security measures. Any changes to data usage must be communicated, and identity must be verified before granting access to personal information. The policy should be reviewed and updated annually, with all amendments shared with relevant parties.

What should a company do if they are in the process of completing SOC2 compliance and a client requests a current SOC2 report?

• If a client is asking for your SOC 2 report but you’re not finished yet, you do have a few options depending on your stage:

  1. Be Transparent About Status

  Let the client know you are actively pursuing SOC 2 and where you are in the process (readiness, audit window, or report drafting).

  Many companies just want to know you are on the path — giving them a timeline can often satisfy their concern.

  2. Provide a SOC 2 “Bridge” Alternative

  SOC 2 in Progress Letter (a.k.a. “Letter of Engagement” or “Audit in Progress” letter): Your auditor can provide a signed statement confirming you are undergoing SOC 2, with an expected completion date.

  This helps reassure customers that independent validation is in progress.

  3. Offer Interim Evidence

  If they need assurance right now, you can give them:

  Policies & Controls Documentation (security policies, access controls, monitoring procedures).

  Other Certifications (ISO 27001, CSA STAR, etc. if you have them).

  Pen Test or Security Reports (recent third-party penetration test, vulnerability scans).

  Trust Center / Security Whitepaper summarizing your security posture.

  These can show your commitment while the formal SOC 2 is pending.

  4. Negotiate Expectations

  If SOC 2 is a hard requirement (e.g., for procurement or contract signing), you may need to push for an extension or conditional approval while your audit is underway.

  Sometimes offering a NDA-protected look into your controls can buy you time.

  Bottom line: You can’t deliver a SOC 2 report until your audit is finished, but you can usually satisfy clients by:

  Giving them a timeline + confirmation from your auditor.

  Supplementing with alternative evidence (policies, pen test, security docs).

  Positioning your “audit in progress” as a proactive move toward compliance.

What's the difference between SOC 2 & SOC 3?

• SOC 3 is a higher-level summary report for external sharing. SOC 2 includes detailed control information, which may not be suitable for sharing publicly.

When should a customer have confidentiality in their SOC 2 scope?

• Customers handling confidential customer information or helping manage users' sensitive information should include confidentiality in their SOC 2 scope.

When should privacy be included in the scope of a SOC 2?

• If the company handles a lot of sensitive information, including privacy in the scope of SOC 2 is recommended.

Where can I find Secureframe's SOC 2 report?

• Secureframe's most recent SOC 2 report can be found in the Trust Center at https://trust.secureframe.com/. You can access all security and compliance documents, including the SOC 2 report, directly through the Secureframe platform.

Which sections of the SOC2 policy cover password management?

• Access Control Policy

  This policy defines how users are authenticated and authorized to access systems and data. It typically includes:

  Password complexity requirements
  (e.g., minimum length, use of special characters, no reuse, etc.)

  Password rotation frequency
  (e.g., change every 90 days)

  Lockout mechanisms
  (e.g., account lock after X failed attempts)

  Multi-Factor Authentication (MFA) enforcement

  Shared credentials prohibition

  Access review frequency and procedures

Who governs SOC 2 compliance?

• The American Institute of Certified Public Accountants (AICPA).

Who should get SOC 2 certified?

• Any organization offering a B2B service/product, or any B2C organization handling sensitive customer information, should consider obtaining a SOC 2 report.

Why does control C-06 show as "Unmapped" to the SOC 2 framework — is this a bug?

• This is expected behavior, not a bug. C-06 (Confidentiality and security requirements are established in customer agreements) is not mapped to SOC 2 by default in Secureframe — it's mapped to other frameworks like ISO 27001, PCI DSS, and TISAX, but SOC 2 is intentionally excluded. If your compliance program requires this control to align with SOC 2 criteria, you can create a custom mapping directly within Secureframe. Reach out to your CSM or support if you need help setting that up.

Why is SOC 2 control P-10 mapped to SOC 2 but not GDPR?

• SOC 2 control P-10 requires organizations to establish, maintain, communicate, and review/update their privacy policy at least annually. It also includes a requirement to notify users when changes occur.

  In comparison, the GDPR equivalent is best aligned with CCPA-04, which focuses on having a privacy policy in place but does not require annual review, user notification of changes, or explicit communication.

  SOC 2 P-10 → Emphasizes external communication and annual updates.

  GDPR/CCPA-04 → Focuses on the internal requirement to maintain a privacy policy.

  Because the scope and expectations differ (especially around notifications and updates), the controls are not mapped 1:1.

Why might KMS permission key policy restrictions be deactivated in AWS for clients with the SOC2 framework?

• The KMS Permission Key Policy Restriction test is not deactivated specifically because of the SOC2 framework — it's deactivated automatically for any company that hasn't yet met the conditions required for the test to be meaningful. There are two main reasons this happens:

  1. AWS isn't connected yet
  The KMS test is an AWS-specific test. If a client hasn't connected their AWS account to Secureframe, the system automatically disables the test and marks it as "Not Applicable" with the note: "Automatically marked not applicable: AWS is not connected." This happens before any evaluation even takes place.

  2. No CloudQuery scan results exist yet
  Even after AWS is connected, the test has a built-in condition: it only activates once Secureframe has actually scanned the client's AWS environment and found KMS key data to evaluate. Until a CloudQuery scan has run and returned results titled "KMS Key Policy," the system marks the test as disabled with the message: "Automatically marked not applicable: No results exist."

  Once both conditions are met — AWS is connected and a scan has run — the test will automatically re-enable on the next resolution cycle and begin evaluating whether the client's KMS key policies are following best practices (no wildcard principals, limited encrypt/decrypt access).
  Why SOC2 clients notice this more

  SOC2 is a broadly adopted framework used by companies across many infrastructure types. Not every SOC2 client uses AWS, and even those that do may not have connected it at the time the framework is set up — so the test sitting in a deactivated state is a common first impression for SOC2 clients specifically.

  The short answer for customers: It's not deactivated because of SOC2 — it's waiting for an AWS connection and a completed scan. Once those are in place, it activates automatically.

Will hiring an employee outside of the United States impact my SOC 2 audit?

• Hiring employees outside of the U.S. will not impact your SOC 2 audit as long as you follow your internal policies for onboarding, such as access control and termination policies.

Will Windows 10 being phased out create a SOC 2 compliance risk?

• Potentially, yes — but not immediately.
  Once Microsoft stops delivering security patches and updates, using Windows 10 may be considered a vulnerability risk under SOC 2’s security principles (CC4, CC7).

  Recommended approach:

  Document a migration plan to Windows 11 or supported OS versions

  Track this as a risk in the Risk Register

  Apply compensating controls if possible (MDM, EDR, restricted access)

  Auditors primarily want to see awareness and a plan — not instant replacement of every asset.

Trust Services Criteria

How do customers know which Trust Service Criteria (TSC) for SOC 2 should be included in the scope of their audit?

• Security is the only required criterion, but many companies also include availability and confidentiality. Additional criteria may be added depending on the services provided and the type of data handled.

How do external auditor costs scale with additional TSCs in-scope for SOC 2?

• The cost depends on the auditor. Generally, additional TSCs like availability or confidentiality may cost around $1,000. Processing integrity and privacy could cost more depending on the number of unique controls in-scope.

If we do need to keep these controls enabled, what is the minimum we need to implement to satisfy SOC 2 Security TSC requirements?

• If the server room is in scope, implement lightweight, practical controls that satisfy SOC 2 expectations without needing badges or complex systems.

  Minimum recommendations:

  1. Visitor Management (PHYS-02, PHYS-03)

  Implement the simplest possible version:

  A visitor sign-in sheet (paper or digital)

  A basic visitor log (name, date, purpose of visit)

  Visitors must be escorted at all times
  These do not require badges or specialized hardware.

  2. Physical Access Review (PHYS-04)

  Even with only two people having keys:

  Conduct a yearly review of who has server-room access

  Document the review date and confirm access is still appropriate
  This satisfies the SOC 2 requirement.

  3. Physical Security of the Room (PHYS-05)

  For Security TSC only, PHYS-05 is typically tied to Availability, not Security.

  Since the customer is only undergoing Security TSC, PHYS-05 can be disabled with a justification:

  “Control relates to Availability TSC, which is not in scope for this audit.”

  The existing key lock on the door is sufficient if the control is enabled.

  4. Maintenance and Environmental Controls (PHYS-06)

  This applies only if the organization is responsible for:

  UPS/battery backups

  AC units

  Power infrastructure

  Fire suppression

  Other hardware maintenance in the server room

  If these are controlled by building management, PHYS-06 can be disabled, with justification:

  “Environmental/maintenance controls are managed by the building and are outside the organization’s control.”

What are the Trust Service Criteria for SOC 2?

• Security, availability, processing integrity, confidentiality, and privacy.

What if I want to add all 5 Trust Service Criteria to my SOC 2?

• You can add all 5 TSC, but you must work with your auditor first. Adding these will likely increase the cost and controls of your audit.

What SOC 2 Trust Service Criteria (TSC) does Secureframe support?

• Currently, we support Security, Confidentiality, and Availability. Processing Integrity and Privacy are coming soon.

What Trust Service Criteria should be included during SOC 2 scoping?

• Security is required. Confidentiality, Availability, Processing Integrity, and Privacy are optional. Disable sections in Secureframe for unselected criteria.

What Trust Services Criteria should I include for SOC 2 scoping?

• Security is always required for SOC 2. You may optionally include Confidentiality, Availability, Processing Integrity, or Privacy depending on your services and customer commitments. If not applicable, disable the related requirements under each section in Secureframe to simplify your scope and evidence burden.

Which Trust Service Criteria (TSC) are required for SOC 2?

• Security is the only required TSC for SOC 2. Additional criteria, like availability and confidentiality, may be included based on customer requirements.

Additional customer questions

What is the difference between an audit report and a certification?

• Reports, like SOC 2, provide detailed compliance information, while certifications, like ISO 27001, indicate a pass/fail outcome.

Do you use any subcontractors or service providers to help deliver your product/service? If so, can you please provide their names and the nature of the sub-processing?

Yes, we do. Details about our subprocessors can be found in our SOC 2 report and our subprocessor list at https://secureframe.com/subprocessors.

Are there additional charges for custom services?

Secureframe does not currently offer managed or custom services directly. However, if your organization has unique needs beyond the scope of our platform, we’re happy to connect you with trusted experts from our extensive Partner Network—at no additional charge from us.

We work with a wide range of specialized partners, including:

Certified Auditors – for SOC 2, ISO 27001, PCI DSS, and more

Cyber Insurance Providers – to help you protect against financial risk from cyber incidents

Readiness Partners (vCISOs) – on-demand security leadership without the cost of a full-time hire

Penetration Testers – simulate real-world attacks to identify vulnerabilities

Security Awareness Training Providers – educate your team on cyber hygiene and phishing threats

Vulnerability Scanning Tools – continuously monitor for weaknesses

Script Protection Solutions – defend against malicious script activity

Web App & Network Pen Testers – deep testing for app and infrastructure vulnerabilities

We’ll gladly make introductions based on your specific goals and ensure you're connected to the best possible fit for your needs.

How long would it take a customer to get their letter of engagement once they've signed on with us?

We can send the letter immediately after they've signed with us. Clarify if the letter needs to come from the auditor or Secureframe. Customers typically want proof of SOC 2 audit in process, which can only be confirmed by the auditor, but we can show readiness is in progress once onboarding is complete.

If our existing policies cover most of what’s in the Secureframe template but are missing some sections, what should we do?

We recommend keeping your existing policies if you’re happy with them, but consider adding any missing sections from Secureframe’s templates to strengthen comprehensiveness. This helps ensure better coverage and alignment with SOC 2 expectations.

Is there an option for a one-time purchase instead of a monthly subscription?

Secureframe is built around ongoing compliance, not one-time assessments. Most frameworks (e.g., SOC 2, ISO 27001, HIPAA) require continuous monitoring, annual reviews, and evidence collection over time to remain compliant and pass audits. Because of this, we do not offer a single-purchase option.

Instead, we provide a subscription-based platform that:

Automates evidence collection and monitoring year-round

Keeps your security posture up to date as your systems and personnel change

Ensures you remain audit-ready beyond a single point in time

If your immediate goal is a point-in-time review, you can leverage our platform to run a gap analysis to identify where you stand today. But ongoing compliance requires continuous coverage — which is why Secureframe is offered as a subscription.

Our policies are updated every 3 years, while procedures are updated annually. Secureframe templates show an annual update requirement for both. Should we change our cadence?

Annual reviews are recommended for both policies and procedures. While some frameworks allow multi-year policy reviews, SOC 2 (and Secureframe best practices) recommend reviewing policies and procedures annually to ensure they remain accurate and aligned with current practices.

Tell me about Secureframe partners and how they can help me?

Secureframe offers a wide range of partners to help your organization achieve compliance efficiently and confidently.

Our trusted partners bring specialized expertise across key areas of security and compliance so you can move faster and smarter.

Here are some of the partners and the services they offer:

Auditors - Certified audit firms that can perform SOC 2, ISO 27001, PCI DSS, and other compliance audits.

Cyber Insurance Providers - Offer policies that protect your organization from financial losses related to cyber incidents or data breaches.

Readiness Partners (vCISOs) - Also known as Virtual CISOs, these experts can be hired hourly or for short-term engagements to guide your team through compliance initiatives without the need for a full-time hire.

Penetration Testers - Security professionals who simulate real-world attacks to identify and address vulnerabilities in your systems.

Security Awareness Training Providers - Help educate your employees on cybersecurity best practices, phishing risks, and how to stay secure online.

Vulnerability Scanning Tools - Continuously monitor your systems to detect and report security weaknesses before they’re exploited.

Script Protection Solutions - Prevent malicious scripts and protect against injection attacks in your web applications.

Web Application & Network Penetration Testing - Focused testing to uncover and remediate vulnerabilities in both your web apps and network infrastructure.

SOX, ITGC, and overlap with SOC reporting

Does ITGC SOX require an audit?

Yes, ITGC SOX requires an audit.

What is ITGC SOX?

ITGC SOX refers to Information Technology General Controls under the Sarbanes-Oxley Act, requiring publicly traded companies to implement controls to ensure the integrity of financial reporting systems. It applies to all publicly traded companies listed on U.S. stock exchanges.

What percent of SOC 1 controls are IT related?

About half of SOC 1 controls are IT-related (the same ITGC from SOC 2), with the remainder focused on financial controls and business application controls.

Who does ITGC SOX apply to?

It applies to all publicly traded companies listed on U.S. stock exchanges.