Axipro Resource Hub

SOC 2 is not a certification, and no auditor will ever hand you a SOC 2 certificate. What you receive at the end of the audit is an attestation report: a detailed document, often 60 to 100 pages long, in which a licensed CPA firm expresses a professional opinion on your controls. That distinction sounds like pedantry until a prospect’s security team asks to see your “certificate” and you have nothing that looks like one. This article explains exactly what a SOC 2 report is, what it contains, how it differs from an ISO 27001 certificate, and how to talk about your SOC 2 status without misrepresenting it. Is SOC 2 a Certification or a Report? The Common Misconception About “SOC 2 Certification” Search volume tells the story: far more people look for “SOC 2 certification” than for “SOC 2 attestation,” and sales teams, procurement questionnaires, and even some auditors use the certification shorthand daily. The misconception is understandable. Every other major framework in the compliance stack, from ISO 27001 to PCI DSS, ends in something that looks like a pass. SOC 2 does not work that way, and treating it as if it does leads to awkward conversations during vendor due diligence. Why SOC 2 Is Technically an Attestation, Not a Certification A certification is a binary judgment issued by an accredited body: you meet the standard, or you do not. SOC 2 sits under the AICPA’s attestation standards, primarily SSAE 18 and its later amendments (SSAE 21 updated the relevant examination sections), specifically AT-C section 105 and AT-C section 205. Under those standards, an independent service auditor examines your controls and reports an opinion on them. Nobody “passes.” The auditor attests to what they found, in writing, with evidence. The output is a report, and the report is the entire deliverable. Understanding the SOC 2 Attestation Model What Is an Attestation Engagement? An attestation engagement is a formal examination in which a practitioner evaluates subject matter prepared by another party against defined criteria, then issues a written conclusion. In SOC 2, the subject matter is your system and its controls, the criteria are the AICPA’s Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy), and the party preparing the subject matter is you, the service organization. Security is the only mandatory category; the other four are scoped in based on your service commitments. The Role of the AICPA and Licensed CPA Firms The AICPA (American Institute of Certified Public Accountants) owns the SOC framework and the attestation standards behind it, but it does not perform audits and does not issue anything to your company. Only a licensed CPA firm can conduct a SOC 2 examination and sign the resulting opinion. That licensing requirement is the quality mechanism: the firm’s professional liability, independence rules, and peer review obligations stand behind the report. In practice, this means the assurance you get is only as strong as the auditor’s reputation and independence posture, which is why enterprise buyers often look at who signed the report almost as carefully as they look at what it says. How Attestation Differs from Certification and Accreditation The three terms describe different assurance models. Certification means an accredited certification body confirms conformity with a standard and issues a certificate, as happens with ISO 27001. Accreditation is one level up: it is the process by which national bodies, such as those coordinated through the International Accreditation Forum, authorize those certification bodies to certify in the first place. Attestation involves no certificate and no accreditation chain. A CPA firm examines evidence and expresses an opinion under professional standards. The credibility comes from the auditor’s license and independence, not from a badge. What You Actually Receive After a SOC 2 Audit The SOC 2 Attestation Report Explained The deliverable is a confidential, restricted-use document addressed to your management and intended for your customers, their auditors, and other informed parties. It is dense by design. A prospect’s risk team reads it to understand what your system does, which controls you operate, how the auditor tested them, and what the auditor found. It replaces a certificate with something far more useful: evidence. Key Components of the Final Report Independent service auditor’s opinion. The first section, usually two to three pages, states the auditor’s formal conclusion on whether your system description is fairly presented and whether your controls were suitably designed (and, for Type 2, operating effectively). This is the section report readers check first. Management’s assertion. A signed statement in which your leadership formally asserts that the system description is accurate and that controls meet the applicable criteria. SSAE 18 made this management assertion a mandatory element, which means responsibility for the description sits with you, not the auditor. System description. The longest narrative section was prepared by management against the AICPA’s SOC 2 description criteria. It covers the services provided, infrastructure, software, people, data, processes, subservice organizations, and complementary user entity controls. Trust Services Criteria and controls tested. A mapping of each in-scope criterion to the specific controls you operate. This is where scoping decisions become visible: a report covering Security only looks very different from one covering all five categories. Results of testing. For Type 2 reports, a control-by-control table showing the tests the auditor performed and the results, including any exceptions. Sophisticated readers spend most of their time here, because exceptions and the auditor’s response to them reveal more than the opinion page does. What a SOC 2 Report Is NOT (No Certificate, No Logo, No Pass/Fail Badge) There is no official SOC 2 certificate, no numbered credential, and no register of “certified” companies you can be listed in. The AICPA licenses a standard SOC logo that service organizations may display for a limited time after report issuance, but the logo confirms only that an examination took place. It says nothing about the opinion inside. Anyone selling you a “SOC 2 certificate” as a standalone artifact is selling something the framework does not produce. Important: If

Most teams walk into a SOC 2 audit expecting standard requirements for their password policy: minimum length, 90-day rotation, one uppercase letter, one symbol, and so on. But there is no such checklist. The AICPA never published a list of mandatory password rules, and the federal guidance that most auditors lean on has thrown out half of what passed for best practice a decade ago.  Beyond compliance, this is remains a crucial cybersecurity control: Stolen and brute-forced credentials still drive a large share of breaches, and password policies are the main way to mitigate this risk. This guide covers what SOC 2 expects around passwords, where those expectations come from, and how to build a policy that satisfies an auditor without making your security worse. What Are SOC 2 Password Requirements? SOC 2 password requirements are the access controls that a service organization implements to govern how passwords are created, stored, enforced, and retired, all in service of the Trust Services Criteria. The important word is controls, not rules. SOC 2 does not hand you a specification. It asks whether your controls are suitably designed and operating effectively to keep unauthorized people out of your systems.   The Role of Passwords in the SOC 2 Trust Services Criteria The Trust Services Criteria, developed by the AICPA, are the evaluation standard for every SOC 2 report. Passwords sit inside the Security category, which is mandatory in all SOC 2 engagements, and specifically inside the Common Criteria series CC6, covering logical and physical access. Passwords are one of the most basic logical access controls you have, and one of the most scrutinized, because CC6 is usually the most evidence-intensive part of the entire audit. Relevant Common Criteria: CC6.1, CC6.2, and CC6.3 CC6.1 covers the controls that restrict logical access to systems, infrastructure, and data, this is where your password policy, MFA enforcement, and account lockout settings live. CC6.2 governs how access is granted, modified, and removed, meaning your provisioning workflows, access reviews, and offboarding processes are all evaluated here. CC6.3 focuses on the removal of access when it is no longer needed and the management of privileged credentials specifically. Together, these three criteria map to the full lifecycle of a credential: creation, ongoing use, and retirement. An auditor working through CC6 will expect evidence at every stage.   Does SOC 2 Mandate Specific Password Rules? No. The AICPA is explicit that the Trust Services Criteria do not define the controls an organization must have. You identify and implement controls that meet the criteria, and the auditor evaluates them. That means there is no AICPA-mandated minimum length, no required rotation interval, and no prescribed complexity formula. What the auditor checks is whether your stated controls exist, work, and reasonably prevent unauthorized access. Insider note: Auditors rarely fail you for choosing a 10-character minimum over 12. They fail you when your written policy says one thing and your actual system configuration says another. Consistency between the policy document and the enforced setting matters far more than the specific number. Why Password Requirements Matter for SOC 2 Compliance Preventing Unauthorized Access Credentials are the front door. The 2025 Verizon DBIR found that stolen credentials remained the single most common initial access vector, appearing in 22% of breaches, and that brute force attacks against basic web applications nearly tripled year over year. Strong authentication controls are the difference between an attacker hitting a wall and an attacker walking straight in with a valid login. Reducing Data Breach Risk Weak or reused passwords feed credential stuffing, where attackers replay username and password pairs harvested from earlier breaches against your login pages. Reuse is rampant: research from Microsoft’s Digital Defense Report routinely finds that the majority of people reuse passwords across services. A single leaked password elsewhere becomes a working key to your environment unless your controls catch it. Demonstrating Logical Access Controls to Auditors SOC 2 is an attestation. It is not enough to be secure; you have to prove it with evidence. Well-designed password controls produce exactly the artifacts an auditor wants: configuration screenshots, enforcement logs, MFA reports, and access review records. Good controls and good evidence are two sides of the same coin, and an internal audit process that routinely collects this evidence makes the formal engagement significantly less stressful. Core SOC 2 Password Requirements Although SOC 2 prescribes nothing specific, a defensible password policy almost always addresses the same set of controls. These are what auditors expect to see and what your peers in compliance treat as table stakes. Minimum Password Length Length is the strongest single lever for password entropy, and modern guidance favors it over everything else. A common defensible baseline is at least 12 characters for standard user accounts, with longer requirements for service and admin accounts. NIST SP 800-63B recommends that verifiers support passwords up to 64 characters so that passphrases and password-manager output are never truncated, an important implementation detail that many teams overlook. Password Complexity and Blocklists Old-style complexity rules, one uppercase, one symbol, one number, are fading, and for good reason. They push users toward predictable substitutions without meaningfully raising entropy. The more effective control is a blocklist: screening new passwords against dictionaries of common and previously breached credentials and rejecting matches. Tools like Have I Been Pwned’s Pwned Passwords API make this straightforward to implement. This stops Password1! from sneaking through even though it technically satisfies a legacy complexity rule. Password Rotation and History Forced periodic rotation is the control most teams keep out of habit, and it is also the one that modern guidance most clearly discourages. Rotation pushes users toward predictable patterns, Spring2025 becoming Summer2025, without improving security in any measurable way. Password history settings, which prevent the immediate reuse of recent passwords, still have a place, but blind calendar-based expiry should be replaced with event-driven resets: force a change when there is evidence of compromise, not because the calendar says 90 days have passed. Account Lockout After Failed Login Attempts An account

The identity and access management market will pass $25 billion in 2026, and it is crowded with vendors that all make the same promise: the right people get the right access to the right resources at the right time. The hard part of any IAM solutions comparison is not finding capable products. It is that the leading platforms were each built to solve a different problem first, then expanded outward. Okta started with access. SailPoint started with governance. CyberArk started with privilege. Choose by brand reputation alone, and you risk buying a governance tool to solve an access problem, or paying enterprise prices for capabilities a mid-market team will never switch on. This guide compares the major providers by what they are actually good at, then walks through how to match one to your environment. What Is an IAM Solution? An IAM solution is the set of technologies that manages digital identities and controls what each identity can access. NIST frames the goal simply: ensure the right people and things have the right access to the right resources at the right time. In practice, that breaks into a few core functions: authenticating users (proving they are who they claim), authorizing them (deciding what they may do), and administering the account lifecycle as people join, move, and leave. The category splits into recognizable disciplines. Access management (AM) handles authentication and single sign-on. Identity governance and administration (IGA) handles who should have access and proves it to auditors. Privileged access management (PAM) protects the high-value accounts that can change infrastructure or read sensitive data. Most vendors now sell across these lines, but few are equally strong in all of them. That gap is the whole reason a comparison is worth doing. Why Comparing IAM Solutions Matters in 2026 Identity is now the primary attack surface. Stolen credentials and phishing remain among the top routes attackers use to get inside, which is why identity spending keeps climbing even when other security budgets flatten. The IAM market reached roughly $22 billion in 2025 and is on track for about $25 billion in 2026, growing near 15 percent a year, according to Fortune Business Insights. Two shifts make the comparison harder than it was a few years ago. First, the workforce went hybrid and cloud-first, so identity has to span on-prem systems, SaaS, and multi-cloud at once. Second, machine identities exploded. Your choice of platform now locks in how well you can govern not just employees but the service accounts, tokens, and AI agents multiplying across your environment. Gartner has reported that roughly 48 percent of organizations still lack a written IAM strategy — a serious problem, because a comparison is worth little if it is not anchored to documented requirements. Vendor demos are designed to make every product look like the obvious answer. Key Criteria for Comparing IAM Solutions A useful comparison rests on a consistent scorecard rather than the feature checklists vendors supply. The criteria below are the ones that tend to decide satisfaction two years after purchase. Core Identity and Access Capabilities Start with the fundamentals: single sign-on, multi-factor authentication, lifecycle provisioning and deprovisioning, and access certification. The differentiator in 2026 is adaptive, risk-based authentication that weighs device, location, and behavior before granting access, alongside phishing-resistant methods such as passkeys. A tool that only does password-plus-OTP is already behind. Deployment Options: Cloud-Native, Hybrid, and On-Premises Deployment model shapes cost, speed, and control. Cloud-native SaaS platforms deploy fastest and shift maintenance to the vendor. On-prem suits organizations with strict data-residency rules or deep legacy systems. Hybrid is the common reality, and the question to ask is how gracefully a platform bridges old and new — not whether it claims to. Integration Capabilities with Existing Infrastructure An IAM platform is only as good as its connectors. Look for prebuilt integrations with your core systems, directory services, HR platforms, and major SaaS apps, plus open standards support: SAML, OIDC, SCIM, and increasingly standards for continuous authorization. A thin connector catalog means custom engineering, which is where budgets quietly disappear. Scalability for Enterprise vs. Mid-Market Organizations Scale is not only user count. It is the number of applications, directories, and identity types a platform can govern without performance or administrative strain. Enterprise suites assume a dedicated identity team. Mid-market tools assume a stretched IT generalist. Buying the wrong tier means either paying for unused complexity or hitting a ceiling within two years. Pricing Models and Total Cost of Ownership Headline per-user pricing rarely reflects real cost. Implementation, professional services, connector licensing, premium support, and the internal staff time to run the platform often exceed the subscription itself. Compliance and Audit Support For regulated industries, audit support is a core feature, not a bonus. Strong platforms run access certification campaigns, segregation-of-duties checks, and audit-ready reports aligned with frameworks such as SOX, HIPAA, ISO 27001, and PCI DSS. The NIST Digital Identity Guidelines (SP 800-63, revised in 2025) are a useful reference for the assurance levels your authentication should meet. Vendor Support, Stability, and Roadmap You are buying a multi-year relationship. Financial stability, support quality, and a credible roadmap matter as much as today’s feature set, especially as the market consolidates and converges. A vendor that gets acquired or pivots can leave you maintaining a product on a slow decline. Pro Tip: Comparing Quotes When you compare quotes, normalize them to a three-year total cost of ownership that includes implementation and at least one major version upgrade. Vendors that look cheap per seat sometimes carry the heaviest services bill, and the gap usually shows up in year one, not at signing. IAM Solutions Compared: The Leading Providers The vendors below dominate enterprise shortlists. Each entry notes the problem the platform solves best — which is the most reliable way to read past the marketing. Okta Workforce Identity Cloud Okta is the largest independent identity vendor and was named a Leader in the 2025 Gartner Magic Quadrant for Access Management for the ninth straight year. Its strength is breadth of

A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.

Most SOC 2 auditors will pick a handful of recent hires from your employee list and request one specific artifact: the completed background check, dated before the start date, sourced from a documented vendor. If you cannot produce it, that is an exception in your report. The control sits inside CC1.4, the Common Criteria provision the AICPA derives from COSO Principle 4, and it is one of the most reliably tested items in a first-year SOC 2 examination. Background screening is not the most technically complex part of SOC 2. It is, however, one of the most procedurally fragile. The policy looks simple on paper. Then a contractor starts a week early because someone needed help shipping a release, the vendor screening gets postponed, and a year later an auditor finds the gap in twenty minutes. This guide explains what SOC 2 actually requires when it comes to background checks, what auditors look for in practice, and how to build a screening programme that holds up under sampling. What Is a SOC 2 Background Check? A SOC 2 background check is the pre-employment screening a service organisation performs to verify that the people it hires can be trusted with access to systems and data inside the SOC 2 scope. It is the operational evidence that supports the abstract principle baked into the Trust Services Criteria: the organisation hires competent people of sound integrity, and it can prove it. In practice, that means a documented check performed by a third party that returns verified information about identity, criminal history, employment history, and, depending on the role, education and credit. The check is run against every new hire before they get logical or physical access to systems within scope. The result is stored, mapped to a named employee, and retrievable on demand. It is worth being clear on one thing: SOC 2 does not prescribe what a background check must contain. The AICPA criteria describe outcomes, not procedures. Your policy is what defines what gets checked, on whom, and how often. The auditor then tests whether you followed your own policy.   Why SOC 2 Background Checks Are Important Insider risk is one of the few attack vectors that perimeter security cannot fix. An employee or contractor with legitimate credentials and undisclosed motives sits inside the network from day one. Background checks are how mature security programmes reduce the probability of that scenario before it begins. According to the Verizon 2024 Data Breach Investigations Report, insider threats continue to represent a persistent and costly category of security incidents, reinforcing why personnel vetting remains a foundational control. Auditors care for a related reason. The Control Environment criteria (CC1) sit at the top of the SOC 2 framework because everything else rests on the assumption that the people running the controls are competent and trustworthy. Skip the screening step, and the rest of the audit is built on a weaker foundation. That is why background check evidence is one of the first things auditors sample, and why a missing or late check shows up as an exception even when the rest of your control environment is strong. Insider Note: Auditors do not just check that the screening happened. They check the timing. A background check completed two months into employment is often treated the same as no check at all, because access to in-scope systems was granted before the control was operative. Time stamps matter as much as the document. SOC 2 Background Check Requirements Which Trust Service Criteria Require Background Checks? Background checks are explicitly referenced in the Common Criteria that apply to every SOC 2 engagement, regardless of which optional Trust Services Categories you include. The two controls that matter most are CC1.1 and CC1.4. CC1.1 establishes the entity’s commitment to integrity and ethical values. Background checks support this by demonstrating due diligence in selecting people who meet the organisation’s standards of conduct. CC1.4 is more direct: it derives from COSO Principle 4, which states that the entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. Within CC1.4, evaluating individual backgrounds is named as a specific point of focus. That is the hook auditors use. Because these are Common Criteria, they apply regardless of whether you are scoping Security only or adding Availability, Confidentiality, Processing Integrity, or Privacy. There is no version of SOC 2 that escapes them. Who Needs to Be Background Checked for SOC 2? The short answer: anyone whose role gives them logical or physical access to systems, data, or facilities within your SOC 2 scope. The longer answer requires you to draw the line in your own policy and stick to it. At a minimum, this includes full-time employees who join the organisation after the policy is in place. Most mature programmes extend the requirement to part-time employees, contractors who receive credentials, and outsourced personnel performing in-scope work. Vendors are usually handled differently — through contractual flow-down requirements rather than direct screening — but the principle is the same: people inside the trust boundary must be vetted. Roles with privileged access (engineers with production credentials, finance staff with payment system rights, support personnel handling customer data) often warrant deeper screening than baseline roles. Documenting this risk-based approach in your policy is good practice and helps you defend the design of your control during the audit. What Types of Checks Must Be Performed? The Trust Services Criteria do not specify which checks to run. That decision sits with the organisation, informed by role, jurisdiction, and regulatory context. A common baseline for SOC 2 purposes covers several distinct areas. Identity verification confirms the candidate is who they claim to be. Criminal history — national, state, or county-level depending on jurisdiction — flags relevant offences. Employment verification confirms the work history disclosed during hiring. Education verification matters for roles where credentials are material. For positions touching finance, payments, or fiduciary responsibility, a credit check may be appropriate. For roles with global reach, a global