The CMMC is vast in coverage and can easily become overwhelming. It includes 110 security controls for each level, excluding level 1, which has only 15, with many encryption controls required throughout. This guide breaks down exactly what the four core encryption controls demand, how they apply across certification levels, and where assessors consistently find gaps that could have been caught months earlier. Whilst most of these controls are straightforward, one stands out on the Defense Industrial Base Cybersecurity Assessment Center’s list of most commonly failed controls: SC.L2-3.13.11, which mandates FIPS-validated cryptography for protecting Controlled Unclassified Information (CUI). This is not because it is technically complex. It is because most contractors misunderstand what it truly requires. The mistake is almost always the same: assuming that using AES-256 is enough. It is not. CMMC encryption requirements are about validated modules, not algorithms, and that distinction is what fails organisations that believed they were ready. What Are the CMMC Encryption Requirements? CMMC 2.0 is the Department of Defense’s framework for verifying that contractors protect sensitive defense information. It operates on three certification levels: Level 1, Basic protection of Federal Contract Information (FCI) Level 2, Protection of CUI in alignment with NIST SP 800-171 Level 3, Protection of the most sensitive CUI against advanced persistent threats Encryption requirements live primarily at Level 2 and above. With CMMC, the requirement for FIPS 140 validation now applies to every member of the Defense Industrial Base (DIB), an estimated 215,000 companies, that handles CUI. Every system that performs encryption and touches CUI must use FIPS-validated cryptography. That is a significant shift: previously, FIPS validation was largely reserved for vendors selling directly to federal agencies. The timeline is active. The CMMC Acquisition Rule became effective November 10, 2025, with Phase 2, mandatory C3PAO assessments for Level 2 contracts, beginning November 10, 2026. The 4 Core CMMC Encryption Controls Explained Three controls form the backbone of CMMC’s encryption requirements. Understanding each one separately matters, because failing any of them has direct consequences on your assessment score. Control Name What It Requires Applies To SC.L2-3.13.11 FIPS-Validated Cryptography Cryptographic modules must hold a valid NIST CMVP certificate Any system that handles CUI SC.L2-3.13.8 CUI in Transit Cryptographic mechanisms must protect CUI across all transmission channels Networks, email, file transfers, APIs SC.L2-3.13.16 CUI at Rest CUI stored on any system must be encrypted Servers, workstations, databases, backups SC.L2-3.13.10 Cryptographic Key Management Keys must be generated, stored, and revoked in a controlled, documented process All systems using encryption to protect CUI MP.L2-3.8.7. CUI on Media Encryption must extend to physical and removable media USB drives, external disks, backup tapes, laptops SC.L2-3.13.11: Employ FIPS-Validated Cryptography to Protect CUI This is the headline control and the most misunderstood. A common mistake is confusing cryptographic algorithms with cryptographic modules. The CMMC requirement is about the module, not just the algorithm. You can run AES-256 across your entire environment. If the module implementing it has not been validated through NIST’s Cryptographic Module Validation Program (CMVP), you are not compliant. The algorithm is not the certificate. Pro Tip During an assessment, you will be asked to provide the FIPS certificate number for each product that handles CUI, not a vendor’s claim that they “support AES-256.” Have those certificate numbers documented before the assessment starts. SC.L2-3.13.8 and SC.L2-3.13.16: CUI in Transit and at Rest SC.L2-3.13.8 requires cryptographic mechanisms to protect CUI during transmission, covering all communication channels: network connections, email, file transfers, and API communications. SC.L2-3.13.16 requires protection of CUI at rest. Neither control names a specific algorithm, but the FIPS validation requirement from 3.13.11 applies across both. SC.L2-3.13.10: Establish and Manage Cryptographic Keys Encryption without key management is security theatre. This control requires that keys be generated, stored, and revoked in a controlled, documented way. A compromised key renders all your encryption irrelevant regardless of algorithm strength. MP.L2-3.8.7: Control Access to CUI on Media This control extends encryption requirements to physical and removable media. CUI stored on a USB drive, an external hard disk, or a backup tape must be protected. Contractors who focus on network-level encryption and forget about the laptop bag sitting in a car park consistently fail this one. CMMC Encryption Requirements by Certification Level Level 1 covers organisations handling only FCI. The controls are foundational and do not explicitly mandate encryption, though it remains a recommended practice. This changes sharply at Level 2. Under the CMMC scoring methodology: 5 points deducted if no cryptography is employed 3 points deducted if cryptography is present but not FIPS-validated Maximum score: 110 | Minimum passing threshold: 88 Getting SC.L2-3.13.11 wrong costs points you cannot afford to lose. Level 3 introduces additional requirements aligned with NIST SP 800-172, including enhanced key management controls, stricter access controls on cryptographic infrastructure, and greater scrutiny of the supply chain around cryptographic tools. Pro Tip According to research by Merrill Research and CyberSheath, only 4% of defense contractors are fully prepared for CMMC certification based on third-party assessment criteria, while 75% believe they are compliant based on self-assessment. The gap is widest in technical controls, with encryption and key management among the most common failure points. What Is FIPS-Validated Cryptography and Why Does It Matter? FIPS stands for Federal Information Processing Standards. FIPS 140, developed by NIST, sets the benchmark for cryptographic modules intended to protect sensitive information. It requires that cryptographic modules be tested by accredited third-party laboratories and certified by NIST, a process managed through the Cryptographic Module Validation Program (CMVP). FIPS 140-2 vs. FIPS 140-3 FIPS 140-3 is the newer standard, published March 22, 2019, and aligns with the international ISO/IEC 19790:2012(E) standard. Both remain acceptable under current CMMC requirements. FIPS 140-3 introduces stricter requirements around physical security, key management, and testing methodologies, and will likely become the primary standard as the framework evolves. If your vendor holds a current FIPS 140-2 certificate and that module remains on NIST’s active modules list, you are covered for now, but plan your migration path. Acceptable Encryption
In March 2026, an anonymous whistleblower published what may be the most detailed exposé of compliance fraud the technology industry has ever seen. The target: Delve, a Y Combinator-backed startup valued at $300 million that promised to get companies SOC 2 certified in days using AI. The allegation: that Delve had been fabricating audit evidence, generating auditor conclusions before any auditor reviewed client data, and getting unaccredited Indian certification mills to rubber-stamp the results. If you work in tech and care about security compliance, or if you were a Delve customer, this story matters to you. What Actually Happened Delve was founded in 2023 by MIT dropouts Karun Kaushik and Selin Kocalar. The pitch was compelling: use “agentic AI” to compress months of painful compliance work into a few days. By mid-2025, the company had raised $32 million in Series A funding, claimed over 1,000 customers in 50 countries, and had become one of the most talked-about names in the compliance automation space. Then, in December 2025, an email went out to hundreds of Delve clients. It alleged that Delve had leaked a publicly accessible Google spreadsheet containing hundreds of confidential audit reports, and that those reports were fraudulent. Delve’s CEO dismissed it as “an AI-generated email with falsified claims.” That denial turned out to be harder to sustain than expected. In March 2026, the anonymous account Deepdelver published a detailed technical analysis of the leaked database. The findings were striking. Across 533 leaked reports covering 455 companies, the same auditor conclusion language appeared word for word, including an identical grammatical error. Auditor conclusions and test results had been generated before any client even provided their company information. The auditors signing off were not the US-based CPA firms Delve had advertised, but Indian certification mills operating through empty shell addresses. Inc. Magazine covered the initial story in detail. Read the full article here. Will Affected Companies Lose Their SOC 2 Certification? The short answer is no, not automatically. SOC 2 reports are issued by independent CPA firms, not by compliance platforms. Delve was the evidence collection and preparation tool. The auditor signed off separately. There is no central SOC 2 registry, no revocation authority, and no body that automatically invalidates a certificate because the platform used to prepare it has been accused of fraud. The certificate exists. It is technically still valid. But a certificate is only as credible as the evidence behind it. If the controls it claims were in place were never actually implemented, if the board meeting minutes were identical boilerplate, if the penetration test never happened, if the device security screenshots were one-off manual uploads rather than evidence of continuous monitoring, the certificate is not a record of real compliance. It is a document waiting to be challenged. The moment a Delve client goes to renew with a reputable auditor, that auditor will look at the evidence. They will find gaps. That renewal failure is when the certificate effectively collapses, and it almost always happens at the worst possible time. Review our SOC 2 compliance checklist to understand exactly what a legitimate audit requires. The Three Situations Every Delve Client Is In Right Now Not every Delve client faces the same risk. Understanding which situation you are actually in is the most important thing you can do right now. Situation 1: Your controls are real, just poorly documented. Your underlying security practices are solid. Delve’s platform generated sloppy evidence around them, but the controls themselves exist. A gap assessment, a cleanup, and a fresh audit with a reputable firm is all you need. Manageable. Situation 2: You have gaps between what your certificate claims and what exists. Some controls were implemented, some were not. The Delve platform made it very easy to click through pre-populated forms and never notice the difference. These gaps are fixable — but only if you find them before your next renewal, your next enterprise customer review, or your next M&A process does. For a deeper understanding of what a proper gap analysis involves, see our detailed guide to gap analysis. Situation 3: Significant controls were never implemented. This creates real commercial, contractual, and in some cases legal exposure. It is particularly serious for companies that handle health data under HIPAA or process EU resident data under GDPR, and for any company that has won government or federal contracts on the basis of these certifications. All three situations look identical from the outside right now. Your certificate exists. Your trust page is live. Nothing has visibly broken. The only way to know which situation you are in is to actually look The Consequences Nobody Is Fully Reporting Most coverage of this story has focused on Delve itself. The more important story is what happens to Delve’s clients over the next 12 months. The enterprise customer risk. Delve’s questionnaire AI was answering vendor security questionnaires on behalf of clients, claiming controls, MDM systems, penetration tests, backup restoration simulations, that the platform demonstrably never verified. Delve clients were making specific false representations to their own enterprise customers during procurement. If any of those customers later suffers a breach and traces it back to a vendor that misrepresented its security posture, the liability chain is clear. This is one of the common pitfalls in SOC 2 that organisations rarely anticipate until it is too late. The HIPAA exposure is more serious than reported. The Deepdelver report identifies multiple Delve clients that process protected health information for millions of US citizens. Under HIPAA, penalties for compliance violations escalate from fines to criminal charges depending on whether the violation was knowing or unknowing. The critical legal threshold here is December 2025. Companies that received the breach notification email and took no meaningful action after that point have a documented timestamp of when they were put on notice. The distinction between unknowing and knowing violation may hinge on that date. GDPR creates cross-border exposure. Under Article 83 of the GDPR, fines can reach 4% of global annual revenue
If you work with the U.S. Department of Defense in any capacity, CMMC compliance is not optional. It is the price of admission. And if you are not prepared, it could cost you your contracts, your reputation, and your seat at the table in the defense industrial base. This guide breaks down everything you need to know about CMMC compliance clearly, honestly, and without the jargon overload. What Is CMMC Compliance? CMMC stands for Cybersecurity Maturity Model Certification. It is a framework developed by the U.S. Department of Defense (DoD) to ensure that defense contractors and subcontractors adequately protect sensitive government information from cyber threats. In plain terms: if you handle federal data, especially sensitive technical or operational information, the DoD wants proof that your cybersecurity practices are up to standard. Not a promise. Actual, verified proof. CMMC compliance means meeting a defined set of cybersecurity practices and, depending on your level, having those practices certified by an accredited third-party assessor, also known as a C3PAO (Certified Third-Party Assessment Organization). It is structured, tiered, and increasingly enforced, particularly since the final CMMC rule was formally codified into federal acquisition regulations in December 2024. Why CMMC Compliance Matters for Defense Contractors The defense sector is one of the most targeted industries for cyberattacks. According to IBM’s Cost of a Data Breach Report, the average cost of a data breach reached $4.45 million in 2023, and breaches involving government data carry consequences far beyond the financial hit. Foreign adversaries, particularly nation-state actors, have been systematically targeting defense contractors to steal intellectual property, weapons designs, and operational intelligence. The DoD created CMMC specifically to close the gaps in the Defense Industrial Base (DIB) cybersecurity posture. For defense contractors, CMMC compliance matters for three hard reasons: Contract eligibility. CMMC requirements are embedded directly into DoD contract solicitations. If you do not meet the required CMMC level, you cannot bid. Full stop. Legal and regulatory liability. Under the False Claims Act, misrepresenting your cybersecurity compliance when submitting to a federal contract can result in significant legal exposure, treble damages, and penalties. Supply chain trust. Even if you are a subcontractor, your prime contractor is responsible for ensuring your compliance. Failure on your part puts their contracts at risk too. The History and Evolution of CMMC From CMMC 1.0 to CMMC 2.0: What Changed? CMMC was first introduced in 2020 as CMMC 1.0, a five-level model that drew heavily from existing NIST frameworks. It was ambitious but widely criticized for being overly complex, expensive to implement, and difficult to scale, especially for small and medium-sized businesses in the defense supply chain. In response to industry feedback, the DoD released CMMC 2.0 in November 2021, streamlining the model significantly. The five levels were reduced to three. The most notable change was the elimination of unique CMMC-specific practices, bringing the framework into direct alignment with NIST SP 800-171 and NIST SP 800-172. CMMC 2.0 also introduced a critical flexibility provision: certain Level 2 contractors may be permitted to perform annual self-assessments rather than requiring a third-party audit, depending on the sensitivity of the information they handle. The final CMMC rule was published in the Federal Register in December 2024, officially codifying CMMC 2.0 into the Defense Federal Acquisition Regulation Supplement (DFARS). How CMMC Relates to NIST SP 800-171 and DFARS NIST SP 800-171 is the foundational document underpinning CMMC Level 2. It outlines 110 security practices across 14 control families designed to protect Controlled Unclassified Information (CUI) in non-federal systems. DFARS clause 252.204-7012 has long required defense contractors to comply with NIST SP 800-171 on a self-attestation basis. The core problem? Self-attestation created significant inconsistency and allowed non-compliant contractors to fly under the radar. CMMC changes that by adding mandatory third-party verification for a large portion of the DIB, bringing real accountability into the equation for the first time. The Three Levels of CMMC 2.0 Explained CMMC 2.0 organizes compliance into three progressive levels. Each level corresponds to the type of information your organization handles and the sophistication of threats you may face. CMMC Level 1: Foundational Who it applies to: Contractors who handle Federal Contract Information (FCI) but not CUI. Requirements: 17 basic cybersecurity practices drawn from FAR clause 52.204-21. Assessment method: Annual self-assessment with an executive affirmation submitted to the Supplier Performance Risk System (SPRS). Level 1 is the baseline. Think good cyber hygiene, things like using antivirus software, controlling who has access to systems, and keeping your software updated. Not glamorous, but non-negotiable. CMMC Level 2: Advanced Who it applies to: Contractors who handle Controlled Unclassified Information (CUI). Requirements: All 110 practices from NIST SP 800-171, organized across 14 domains. Assessment method: Either triennial third-party assessment by a Certified Third-Party Assessment Organization (C3PAO) or annual self-assessment, depending on contract criticality. This is where the majority of the defense contractor community lands, and where most of the compliance effort (and cost) is concentrated. If your organization touches CUI in any meaningful way, Level 2 is almost certainly your target. CMMC Level 3: Expert Who it applies to: Contractors supporting the DoD’s most critical programs, handling CUI that presents higher-risk threat vectors, often involving advanced persistent threats (APTs). Requirements: 110+ practices from NIST SP 800-171 plus select practices from NIST SP 800-172. Assessment method: Government-led assessment conducted by the Defense Contract Management Agency (DCMA). Level 3 is the top tier. If you are here, you already know what you are dealing with, and so do your adversaries. CMMC Level Information Type Practices Required Assessment Type Level 1: Foundational FCI 17 (FAR 52.204-21) Annual self-assessment Level 2: Advanced CUI 110 (NIST SP 800-171) C3PAO or self-assessment Level 3: Expert CUI (high-value) 110+ (NIST SP 800-172) Government-led (DCMA) Who Needs to Be CMMC Compliant? Prime Contractors Any organization that holds a DoD contract involving FCI or CUI must comply with the applicable CMMC level. Prime contractors are typically well-resourced enough to navigate the process, but that does not make them exempt from the hard work, or from the
The “SSAE 18 vs SOC 2” debate typically surfaces when buyers, vendors, and even internal teams are all talking about the same general assurance problem, but using the wrong labels. A procurement team asks, “Do you have SSAE 18?” A founder says, “We’re going for SSAE 18 certification.” A customer security team asks for an “SSAE 18 SOC 2 report.” Everyone is circling the same planet, but not always landing on the right terminology. SSAE 18 and SOC 2 are not competing things. They are related, but they are not interchangeable. The AICPA defines SOC 2 as an examination and report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. SSAE 18, by contrast, is the attestation standard framework under which these kinds of engagements are performed. That distinction matters because buyers often ask for the wrong artifact. If you answer the wrong question, you can waste months preparing the wrong report. Quick Answer: SSAE 18 Is a Standard; SOC 2 Is a Report The simplest accurate explanation is this: SSAE 18 is the professional attestation standard; SOC 2 is the report deliverable. The standard tells the auditor how to perform the engagement. The report is what your customers actually read. The AICPA states that SSAE No. 18 was issued as part of its attestation clarity project, which clarified and recodified attestation standards. The same organization also explains that SOC reports are part of the AICPA’s broader SOC suite of services used to communicate controls at service organizations. So when someone says, “We need SSAE 18,” what they usually mean is one of two things: either they want a SOC 1 report for financial-reporting-related controls, or they want a SOC 2 report for security and broader system controls. How SSAE 18 Relates to SOC 1, SOC 2, and SOC 3 SOC 1 addresses controls at a service organization that are relevant to a user entity’s internal control over financial reporting. The AICPA positions SOC 1 specifically for management of user entities and their financial statement auditors. SOC 2 addresses controls relevant to the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. It is designed for customers and other specified users who need detailed information about system controls. SOC 3 covers the same trust services subject matter as SOC 2, but in a general-use format with less detail, so it can be freely distributed. (Think of it as the marketing-friendly version.) In plain English: SSAE 18 sits underneath the engagement methodology; SOC 1, SOC 2, and SOC 3 are the reporting formats and scopes that come out of it. What Is SSAE 18? SSAE 18 stands for Statement on Standards for Attestation Engagements No. 18. It is an AICPA-issued attestation standard used in examinations, reviews, and agreed-upon procedures for nonissuers. The AICPA describes SSAEs as applicable to the preparation and issuance of attestation reports for nonissuers, and specifically notes that SSAE No. 18 completed the attestation clarity project through clarification and recodification. Who Issues SSAE 18 and Who Performs the Engagement The AICPA Auditing Standards Board (ASB) issues SSAE standards. The actual engagement, however, is performed by an independent CPA firm or service auditor. That division of labor is important. Your company does not “self-issue” SSAE 18. A CPA firm performs an attestation engagement under that standard and then issues the related report. Insider Tip When a buyer asks whether you are “SSAE 18 certified,” they are using market shorthand, not technical language. The better response is: “We have a SOC 2 Type 2 report issued by an independent CPA firm under the applicable attestation standards.” What SSAE 18 Replaced (SSAE 16 / SAS 70 Context) Historically, the service-organization reporting world moved from SAS 70 to SSAE 16, and then to SSAE 18. The AICPA’s clarity and convergence work eliminated the old SAS 70 framing, established the SOC-branded reports, and recodified the underlying attestation standards into SSAE 18. The standard was introduced in 2016 and implemented in 2017 as part of this evolution. (For international context, SSAE 18’s closest equivalent is ISAE 3402, issued by the International Auditing and Assurance Standards Board.) That is why older buyers may still talk in legacy language. They remember SAS 70. Mid-generation buyers remember SSAE 16. Today’s market usually asks for SOC 1 or SOC 2, but sometimes with yesterday’s vocabulary still attached. Which Engagements Fall Under SSAE 18 Within the SOC context, SSAE 18 governs how the practitioner performs examinations that lead to reports such as SOC 1, SOC 2, and SOC 3. The AICPA’s SOC suite overview frames these offerings as assurance reports used to help assess and address outsourcing risk. What Is a SOC 2 Report? A SOC 2 report is an independent attestation report on controls at a service organization relevant to the Trust Services Criteria. The AICPA defines SOC 2 around the five criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 exists because businesses increasingly outsource critical systems to cloud and SaaS providers, and they want a way to evaluate whether those providers have appropriate controls in place. We’ve written an in-depth guide on what SOC 2 is, which you can read here. What SOC 2 Evaluates (Controls Aligned to Trust Services Criteria) SOC 2 evaluates whether the service organization’s system and controls are suitably designed—and, in a Type 2 engagement, whether they operated effectively over a review period—against the applicable TSC. Security is always part of SOC 2, while Availability, Processing Integrity, Confidentiality, and Privacy are included based on the nature of the service and customer commitments. If you’re unsure which criteria apply to your organization, a gap analysis is a smart first step. SSAE 18 vs SOC 2: Side-by-Side Comparison Category SSAE 18 SOC 2 What it is Attestation standard Report deliverable Issued by AICPA Auditing Standards Board Independent CPA firm (after the engagement) Primary purpose Governs how the engagement is performed Communicates results about controls relevant to TSC Scope Broad attestation framework Security and
Contrary to popular belief, SOC 2 does not mandate a strict list of cryptographic controls. Instead, it evaluates whether an organization has implemented appropriate encryption controls based on risk. That distinction matters: auditors care less about whether you check a specific box and more about whether your encryption strategy effectively protects sensitive data. This guide breaks down how encryption fits into SOC 2 compliance, where auditors look for it, and how to design encryption controls that hold up during a SOC 2 Type I or SOC 2 Type II audit. What “SOC 2 encryption requirements” really means The System and Organization Controls 2 (SOC 2) framework was created by the American Institute of Certified Public Accountants (AICPA) to help service organizations demonstrate that their systems are secure and trustworthy. SOC 2 assessments evaluate controls against the Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. The AICPA’s 2017 Trust Services Criteria (updated with revised points of focus in 2022) is the document auditors reference when evaluating your controls. But here’s the key nuance: SOC 2 is a controls report, not a prescriptive encryption standard. Instead of dictating exact technologies, SOC 2 asks auditors to determine whether controls are appropriately designed and operating effectively to meet the Trust Services Criteria. This means encryption is often expected—especially for sensitive or regulated data—but it’s not universally “required” in every scenario. Scenario Encryption expectation Public marketing website TLS likely required Internal operational logs May depend on risk classification Customer database with PII Encryption almost always expected The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t, even if your encryption is technically sound, expect follow-up questions. How auditors evaluate “appropriate” encryption for your risk profile SOC 2 audits are risk-based. Auditors don’t walk in with a checklist of mandatory algorithms. Instead, they assess whether your encryption posture makes sense given the data you handle. They typically ask questions like: What types of data does the system process? How sensitive is that data? What threats could expose it? What encryption controls mitigate those risks? Organizations that process PII, financial records, or proprietary customer data will be expected to demonstrate stronger encryption controls than a company that only handles non-sensitive internal metrics. Evidence often includes encryption policies, architecture diagrams, key management procedures, configuration evidence from cloud services, and monitoring and audit logs. The point isn’t just having encryption—it’s having evidence that encryption is in place and working as described. If you’re working from a SOC 2 compliance checklist, make encryption evidence a line item, not an afterthought. For a SOC 2 Type I, auditors evaluate control design at a single point in time. They’re asking: “Are these controls designed in a way that should work?” For a SOC 2 Type II, auditors test whether encryption controls operated consistently over time, typically across a 6–12 month period. This is where SOC 2 Type II continuous monitoring becomes essential. It’s one thing to set up encryption correctly on a Tuesday—it’s another to prove it was running properly every day for the last nine months. The goal is to demonstrate that encryption controls align with your data classification and risk management strategy. If you can show auditors that your encryption decisions are deliberate, documented, and proportionate to the risk, you’re in strong shape. If you can’t—even if your encryption is technically sound—expect follow-up questions. Criterion Role of encryption Key focus Security (mandatory) Primary TLS for network communication, secrets protection, key management, access control enforcement Confidentiality Primary Protecting sensitive data at rest (e.g., AES-256, TDE) and in transit Privacy Important Encrypting PII, credentials, and identity documents; works alongside retention and data minimization controls Availability Supporting Encrypted backups, secure recovery data Processing Integrity Supporting Tamper protection during data transmission and processing Security is the only mandatory criterion in every SOC 2 audit, but if you’ve included Confidentiality or Privacy in your scope, encryption becomes a central control,not a supporting one. For organizations weighing SOC 2 against other standards, our comparison of ISO 27001 vs SOC 2 can help clarify the differences. Encryption scope: what auditors will examine Auditors evaluate encryption within the boundaries you define. That means scoping decisions matter as much as the technical implementation. A mature SOC 2 environment classifies data into tiers,public, internal, confidential, and regulated,and applies encryption requirements accordingly. Customer data almost always receives the strictest protections, while internal operational metrics may be risk-based. If you haven’t built a formal data classification policy, expect auditors to flag that gap. Data type Encryption expectation Customer database Mandatory encryption Employee HR records Strong encryption Internal monitoring metrics Risk-based Two scoping pitfalls that auditors flag regularly: production data copied into staging or development environments without encryption (if real data is present, it needs production-grade protections), and unclear cloud shared responsibility. Cloud providers operate under shared responsibility models,infrastructure security may be the provider’s job, but data encryption configuration is almost always yours. Organizations using services like AWS KMS, Azure Key Vault, or Google Cloud KMS must demonstrate what the provider manages, what they manage, and how both are verified. Data in transit and at rest: what you need to encrypt In transit The industry standard is TLS 1.2 or TLS 1.3 for any data crossing a network boundary,external APIs, admin portals, and internal microservices where the risk justifies it. The rule is simple: if sensitive data moves between systems, it should be encrypted. Auditors increasingly ask about internal service-to-service traffic, not just external connections. Organizations using service mesh frameworks or zero-trust models are well positioned here. Don’t overlook remote access (VPNs, bastion hosts, zero-trust gateways), file transfers (SFTP over plain FTP), and certificate lifecycle management,an expired TLS certificate that causes an outage is both an availability problem and evidence that controls aren’t operating effectively. At rest Encryption at rest protects stored data from unauthorized access. The most
Cyberjuice.io and Axipro today announce a strategic partnership designed to help organizations modernize securely, achieve compliance faster, and reduce delivery risk through a fully aligned services model. This partnership brings together Cyberjuice.io’s SaaS compliance automation platform and Axipro’s proven compliance enablement and certification expertise across ISO 27001, SOC 2, GDPR, and other leading frameworks. Cyberjuice.io provides the underlying compliance system of record, while Axipro delivers hands-on implementation, validation, and audit readiness. The result is a coordinated engagement model that unifies technical transformation and certification readiness from day one. Driving Faster, Safer Growth Through Coordinated Delivery Both Cyberjuice.io and Axipro share a commitment to delivering quality, operational clarity, and real business impact. Cyberjuice.io specializes in providing industry-leading compliance workflow automation software. Axipro specializes in compliance implementation, risk assessment, internal audits, and certification facilitation. Together, they close the gap that often exists between engineering teams and compliance objectives. Axipro’s Achievement Plan supports certification readiness in approximately six weeks, backed by more than 10,000 implementation hours and a 100 percent customer satisfaction record. Cyberjuice.io provides a structured, audit-ready compliance platform that operationalizes controls through guided workflows, evidence collection, and continuous monitoring, while Axipro ensures correct implementation, validation, and certification readiness. This partnership transforms compliance from a reactive obligation into a strategic growth enabler. What Customers Can Expect Through this joint offering, organizations gain access to an end-to-end engagement lifecycle covering discovery, solution design, build and integration, validation, launch, and ongoing optimization. During discovery, business objectives, technical architecture, and compliance scope are aligned. Risk exposure and growth plans are evaluated together, not in silos. Post-launch, customers can engage in ongoing compliance monitoring, governance refinement, performance optimization, and internal audit cycles to ensure sustained maturity. The outcome is simple but powerful: secure systems that perform operationally and withstand scrutiny. A Structured Engagement Approach Engagements follow a disciplined, outcome-driven process. The initial consultation focuses on understanding strategic objectives, technical landscape, and certification goals. From there, a jointly designed roadmap defines clear success criteria. Implementation combines technical activities with structured control validation. Evidence collection processes are embedded in workflows. Documentation is generated systematically, not assembled under audit pressure. Finally, teams receive training, governance structures are formalized, and continuous improvement cycles are established. The approach reflects internationally recognized best practices, including those outlined by standards bodies such as ISO and guidance frameworks referenced by the National Institute of Standards and Technology. A Clear Path to Getting Compliant Organizations interested in the Cyberjuice.io & Axipro partnership are encouraged to prepare a high-level overview of their current infrastructure environment, compliance targets, timeline expectations, and operational pain points. The first consultation is designed to assess fit, clarify scope, and outline a practical roadmap. From modernization programs to certification readiness initiatives, the partnership offers a structured path forward. About Cyberjuice.io Cyberjuice.io is a SaaS compliance automation platform, similar to Drata and Vanta, purpose-built for small digital companies and tech startups. The platform helps organizations achieve and maintain certifications such as ISO 27001, SOC 2, GDPR, and NIS2 through guided workflows, automated evidence, policy management, and continuous compliance monitoring — without heavy spreadsheets or reliance on consultants. Cyberjuice.io acts as the system of record for compliance, enabling teams to stay audit-ready as they scale, while partners like Axipro deliver hands-on implementation, advisory, and certification support on top of the platform. About Axipro Axipro is a leading compliance enablement partner delivering gap analysis, implementation, internal audit, penetration testing, and certification support services across ISO 27001, SOC 2, GDPR, ISO 9001, and related frameworks. Axipro blends human expertise with modern automation platforms to simplify compliance and accelerate measurable outcomes. With more than 10,000 implementation hours and a 100 percent customer satisfaction record, Axipro’s mission remains clear: Simplifying compliance, your success, our priority.
If there is one subject that persistently confuses merchants, it is the myths surrounding PCI DSS. Some believe compliance doesn’t apply to them. Others think outsourcing or cyber insurance removes the burden. And many assume that once they’ve passed an assessment, they’re “secure.” These misunderstandings can lead to underestimated risk, insufficient security controls, and ultimately, preventable data breaches. In this article, we’ll break down the most common PCI DSS myths, clarify what the standard actually requires, and explain what businesses should really be focusing on. Let’s begin with the basics. What Is PCI DSS? The Payment Card Industry Data Security Standard (PCI DSS) is a global security framework designed to protect cardholder data wherever it is stored, processed, or transmitted. It was introduced in 2004 by major payment brands and is managed by the PCI Security Standards Council. According to the official council website, PCI DSS applies to “all entities that store, process, or transmit cardholder data.” That includes merchants, service providers, processors, SaaS platforms, call centers, and even companies that indirectly touch payment systems. The current version of the standard contains 12 high-level requirements grouped into areas such as: Secure network architecture Protection of stored cardholder data Strong access control measures Continuous monitoring and testing Information security policies PCI DSS is not optional. It is enforced by acquiring banks and card brands, including Visa Inc. and Mastercard. Now, let’s address the most common PCI DSS myths. Myth 1: Outsourcing Card Processing Makes Us Secure This is perhaps the most widespread misunderstanding. Many organizations assume that because they use a third-party payment gateway or hosted payment page, PCI DSS no longer applies to them. That’s not how it operates. While you can delegate processing tasks, responsibility cannot be delegated. If your website redirects customers to a hosted payment provider, your infrastructure may still be partially in scope. If your staff can access payment dashboards, your access controls are in scope. If your call center handles card details over the phone, your environment is in scope. The PCI DSS is clear: compliance scope depends on how cardholder data flows through or touches your systems. Simply signing a contract with a PCI-compliant service provider does not automatically make your business compliant. In fact, poorly managed third-party integrations are a frequent cause of breaches. According to the Verizon Payment Security Report, many organizations struggle to maintain continuous compliance over time. Verizon’s research has repeatedly shown that validation does not equal sustained security. Outsourcing can reduce scope. It does not eliminate it. If you rely on third parties, you must verify their compliance status, clearly define shared responsibilities, and ensure your own systems are secure. Myth 2: Cyber Insurance Protects Us From PCI DSS Breaches Cyber insurance is valuable. But it is not a substitute for PCI DSS compliance. Insurance can cover certain costs after an incident, but it does not prevent breaches, halt forensic investigations, or safeguard your brand reputation. And most importantly, if you were negligent or non-compliant at the time of the breach, insurers may dispute or reduce coverage. The PCI DSS framework exists to reduce the likelihood and impact of data breaches. Insurance exists to manage residual financial risk. These are two very different functions. Research from IBM Security in the Cost of a Data Breach Report consistently shows that organizations with mature security practices detect and contain breaches significantly faster than those without them. The takeaway is simple: Insurance helps you recover. PCI DSS helps you prevent. You need both, but they are not interchangeable. Myth 3: We Don’t Sell Online, So PCI DSS Isn’t Relevant This misconception is common among brick-and-mortar businesses: ‘If we don’t have e-commerce, PCI DSS doesn’t apply.’ Wrong. PCI DSS applies to any organization that accepts payment cards, whether transactions occur online, in-store, over the phone, or by mail order. The PCI Security Standards Council Guide to Safe Payments for Small Merchants clearly emphasizes that physical terminals, Wi-Fi networks, back-office PCs, and connected systems all create potential exposure points. Small and mid-sized merchants are especially vulnerable. According to Verizon’s Data Breach Investigations Report, a significant percentage of breaches impact small businesses, often due to weak password controls, outdated systems, or misconfigured networks. Even standalone payment terminals connected via IP networks can pose a risk if default passwords are not changed or systems are not properly segmented. The environment doesn’t have to be digital-first to be exploitable. If you accept cards, PCI DSS is relevant. Myth 4: We’re a Small Business With Few Card Payments; PCI DSS Doesn’t Apply to Us Another dangerous assumption. PCI DSS merchant levels are based on transaction volume. However, all merchants must validate compliance, regardless of size. Level 1 merchants are required to undergo an annual on-site assessment by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA), resulting in a Report on Compliance (ROC). Levels 2–4 typically complete a Self-Assessment Questionnaire (SAQ), though some Level 2 merchants must also engage a QSA or ISA depending on their SAQ type. All merchants that store, process, or transmit cardholder data must comply with PCI DSS, but specific validation requirements vary by card brand and acquiring bank, particularly at Levels 3 and 4. The idea that “we’re too small to be targeted” is particularly risky. The National Cyber Security Alliance has reported that a significant percentage of small businesses close within months of a major breach. Financial penalties, legal fees, operational disruption, and loss of trust can be devastating. Small merchants are often targeted precisely because attackers assume defenses are weaker. PCI DSS is not about size. It’s about exposure. If you process even a handful of card transactions, you are within scope. Myth 5: If We’re PCI DSS Compliant, We’re Secure This may be the most subtle and most dangerous , PCI DSS myth. Compliance does not equal security. PCI DSS defines a minimum baseline of controls. It does not guarantee immunity from cyber threats. Nor does it replace a broader cybersecurity strategy. Verizon’s Payment Security Report has consistently shown
SOC 2 compliance can sometimes feel like a needlessly complex Pandora’s box of documentation. But it shouldn’t be. That’s why today, we’ll show you how to easily become compliant with our 12-step SOC 2 compliance checklist.In its simplest form, all the SOC 2 sections point to the same question: Can you prove your controls work? This SOC 2 Compliance Checklist guides you through the process from scoping through audit completion for both SOC 2 Type 1 and Type 2. It is practical, auditor-aligned, and written for teams that want clarity rather than theory. If you want the short version: SOC 2 is not about tools or paperwork. It is about repeatable processes, clear ownership, and evidence that stands up to scrutiny. What is a SOC 2 compliance checklist? A SOC 2 compliance checklist is a structured roadmap that maps your internal controls to the AICPA Trust Services Criteria and prepares your organization for a Type 1 or Type 2 audit. For a full breakdown of SOC 2 requirements, read our detailed SOC 2 guide. How to Use This SOC 2 Compliance Checklist Think of this checklist as a living roadmap, not a one-time document. You should revisit it at four points: before scoping, during readiness, throughout evidence collection, and after the audit for continuous compliance. Type 1 vs. Type 2: Which Checklist Items Change? The core checklist does not change dramatically between Type 1 and Type 2. What changes is time and proof. Type 1 evaluates whether controls are designed correctly at a specific point in time. Type 2 evaluates whether those same controls operated effectively over an observation period, usually 3, 6, or 12 months. This means evidence for Type 2 must show consistency, such as quarterly access reviews, repeated vulnerability scans, and incident response tests that actually occurred. Who Owns Each Workstream SOC 2 is cross-functional by design. Security may lead, but it cannot succeed alone. Engineering typically owns secure SDLC, change management, and logging. IT owns IAM, endpoints, and device management. Legal and HR contribute policies, onboarding controls, and training. GRC or compliance coordinates risk assessment, evidence, and auditor communication. The fastest SOC 2 projects have named control owners with deadlines, not shared responsibility. What “Audit-Ready” Really Means Being audit-ready does not mean “we think we are secure.” It means you can produce clear, dated, and traceable evidence that maps directly to the Trust Services Criteria. Auditors test design, then operation. They expect policies, tickets, screenshots, logs, and approvals. They also expect alignment. If your policy says quarterly, your evidence cannot show annual. The AICPA provides the underlying standard, supported by SSAE 18 and AT-C 205. Pre-Checklist: Confirm You Actually Need SOC 2 Not every company needs SOC 2 immediately. If your customers are SMBs, you may see lighter requirements. If you sell to enterprises, SOC 2 often becomes non-negotiable. Security questionnaires are the strongest signal. When prospects ask about penetration testing, access reviews, and incident response evidence, SOC 2 is usually the cleanest way to respond at scale. Alternatives like ISO 27001, PCI DSS, or HIPAA can be valid. But SOC 2 is uniquely customer-facing, especially in North America. ISO 27001 is excellent for global alignment, while SOC 2 maps directly to buyer trust. The 12-Step Checklist Step 1- Define Scope Scoping mistakes cause more SOC 2 delays than any missing control. Your scope must clearly define the services you provide, the systems that support them, and the access controls. Over-scoping increases cost and complexity. Under-scoping leads to auditor pushback. In-scope systems usually include production cloud environments, CI/CD pipelines, support tooling, and identity providers. In-scope people include employees and contractors with access to customer data. Third parties are addressed as Subservice organization, using either the Carve-out method or Inclusive method. Data classification and flows must identify PII, PHI, or payment data, and how it moves through systems. Action Plan for Scoping Define the Service Commitment List In-Scope Systems Identify In-Scope People Document Third Parties Map Data Flows Validate Scope with Leadership Step 2- Select the Trust Services Criteria All SOC 2 reports include Security (Common Criteria). The others are optional but must be justified. Availability focuses on uptime and disaster recovery. Confidentiality focuses on sensitive data protection. Processing Integrity focuses on system accuracy. Privacy applies when personal data obligations are central. Your report must document why each criterion is included or excluded. Auditors look closely at this rationale. Trust Service Criteria Action Plan Confirm Security (Mandatory) Assess Optional Criteria Document Inclusion Rationale Obtain Executive Sign-Off Step 3- Choose the Audit Path and Timeline Most teams benefit from a readiness assessment before audit. This is often referred to as a Readiness assessment or Gap analysis. Type 1 audits can be completed in weeks once controls are ready. Type 2 timelines depend on the observation period. Six months is the most common balance between speed and credibility. Define control owners early and create an evidence calendar. Late evidence is the enemy of clean audits. Audit Path and Timeline Action Plan Conduct Readiness or Gap Assessment Choose Audit Type Set Observation Period (Type 2) Assign Control Owners Build Evidence Calendar Step 4- Pick an Auditor and Define the Engagement Choose a CPA firm with real SOC 2 experience in your industry. Responsiveness matters more than brand name. Confirm standards, testing approach, sampling expectations, and how subservice organizations are treated. The engagement letter should clearly state scope, period, and deliverables. A clear PBC list process avoids confusion later. Action plan for finding an auditor. Shortlist CPA Firms Review Testing Approach Clarify Subservice Treatment Finalize Engagement Letter Request Preliminary PBC List Step 5- Perform a SOC 2 Gap Analysis Map existing controls to the Trust Services Criteria. Missing policies, undocumented processes, and inconsistent evidence usually surface here. Prioritize high-risk gaps first. Document known exceptions and compensating controls honestly. Auditors prefer transparency over perfection. Gap Analysis Action Plan: Map Controls to Criteria Identify Missing Controls Prioritize by Risk Document Compensating Controls Step 6- Build the Policy and Governance
