What is the ISC2 CSSLP certification?

The Certified Secure Software Lifecycle Professional (CSSLP) is ISC2’s advanced certification for professionals who embed security throughout the entire software development lifecycle — not just at the firewall, but in the requirements document, the threat model, the code review, the CI/CD pipeline, the deployment runbook, and the third-party component inventory. Where CISSP validates broad information security management across eight domains, CSSLP goes deep on a specific and increasingly critical discipline: making software itself secure, from its earliest design decisions to its long-term operational maintenance and eventual decommission.

The credential was created to address a structural gap in how organizations approach security. Traditionally, security was applied at the perimeter — after software was written, tested, and deployed, a security team would attempt to harden what the development team had built. This approach is expensive, slow, and increasingly ineffective: the attack surface of modern software (complex dependency trees, cloud-native microservices, AI model integrations, third-party APIs, open-source components) is too large to secure by wrapping it in controls after the fact. CSSLP validates the ability to do the opposite: apply security controls at every SDLC phase so vulnerabilities are prevented at design time rather than remediated at incident-response time.

In 2026, CSSLP has become a prerequisite for senior application security engineering roles at regulated industries (financial services, healthcare, defense contractors) and at large technology companies that have adopted formal Secure Software Development Frameworks (SSDFs) in response to regulatory mandates from NIST, the EU Cyber Resilience Act, and US Executive Order 14028 on improving the nation’s cybersecurity. Engineers with CSSLP are the practitioners who implement those frameworks at the code and architecture level — the people who write the threat models, run the security design reviews, configure SAST/DAST tooling, manage software bills of materials (SBOMs), and operate the secure CI/CD pipelines that production-scale secure software development requires.

Exam format, prerequisites, and cost

CSSLP is administered as a linear, fixed-form exam (unlike the CISSP Computerized Adaptive Testing format). The exam contains 125 questions to be answered in 3 hours. Questions are multiple choice with a single correct answer. The passing score is 700 out of 1000. The exam fee is $699 USD. Candidates who fail may retake after 30 days, with a maximum of three attempts per year.

CSSLP has a formal experience requirement: candidates must have a minimum of four years of cumulative paid work experience in one or more of the eight CSSLP domains, with at least one year specifically in software development lifecycle security. Engineers who pass the exam without meeting the experience requirement receive an Associate of ISC2 designation and have six years to complete the experience documentation. ISC2 requires CSSLP holders to earn 90 CPE credits per three-year certification cycle and pay an Annual Maintenance Fee (AMF) of $125 per year to maintain the certification — the same maintenance structure as CISSP and other ISC2 credentials.

Domain Weight
1. Secure Software Concepts~10%
2. Secure Software Requirements~14%
3. Secure Software Architecture and Design~14%
4. Secure Software Implementation~14%
5. Secure Software Testing~14%
6. Secure Software Lifecycle Management~11%
7. Secure Software Deployment, Operations, and Maintenance~12%
8. Secure Software Supply Chain~11%

Domain 1: Secure Software Concepts — ~10%

This foundational domain establishes the security principles and frameworks that underpin every other domain. Candidates must understand the core security properties — confidentiality, integrity, and availability (CIA triad) — and their software-specific implications: how a buffer overflow violates integrity, how an injection attack violates confidentiality, how a denial-of-service attack violates availability. The domain covers security design principles: least privilege (every software component operates with the minimum permissions necessary to perform its function), defense in depth (multiple independent security controls so that no single failure exposes the system), fail secure (when a component fails, it defaults to a secure state rather than an open one), economy of mechanism (security controls should be as simple as possible to reduce the attack surface of the control itself), and separation of duties (no single user or process controls an entire sensitive operation from start to finish).

The domain also covers software security standards and frameworks relevant to the exam: OWASP Top 10 (the authoritative ranking of the most critical web application security risks — every CSSLP candidate must know all ten categories, their root causes, and their mitigations), the NIST Secure Software Development Framework (SSDF), the BSIMM (Building Security In Maturity Model) for benchmarking an organization’s software security program, and the concept of security maturity models. Candidates should understand how regulatory requirements — GDPR data minimization and privacy by design, PCI DSS secure coding requirements, HIPAA technical safeguards for software handling PHI — translate into specific software development constraints.

Domain 2: Secure Software Requirements — ~14%

Security requirements define what the software must do (and must not do) from a security perspective before a single line of code is written. This domain tests the ability to elicit, analyze, and document security requirements alongside functional requirements. Candidates must understand the categories of security requirements: authentication and authorization requirements (who can access the system, what actions they can perform, how identity is verified), data protection requirements (which data fields are sensitive, how they must be encrypted at rest and in transit, how long they must be retained and when they must be purged), audit and logging requirements (which events must be logged, at what granularity, and how logs must be protected from tampering), and error handling requirements (what information error messages may expose, how failures must be reported to users vs. logged internally).

The domain tests privacy requirements engineering in depth: GDPR Articles 25 (data protection by design and by default) and 32 (appropriate technical measures) translate into specific software requirements; CSSLP candidates must know how to convert regulatory language into testable software requirements. Misuse cases and abuse cases are a key CSSLP technique: while use cases document intended user flows, misuse cases document how an attacker would attempt to misuse each feature, and abuse cases document how each input could be malformed to cause unexpected behavior. Documenting security requirements as testable acceptance criteria — using Given/When/Then format or equivalent structured specifications — ensures they can be verified in the testing phase.

Domain 3: Secure Software Architecture and Design — ~14%

The architecture and design domain tests the ability to make security decisions that determine the security posture of a system before implementation begins. The most heavily tested technique is threat modeling: a structured process for identifying assets, threat actors, attack vectors, and mitigations at the design stage, when changes are cheapest. Candidates must understand the major threat modeling methodologies — STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) for categorizing threats by type; DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) for risk-ranking threats; and PASTA (Process for Attack Simulation and Threat Analysis) for a business-objective-aligned risk-centric approach. The exam expects candidates to be able to apply STRIDE categories to a given data flow diagram and identify which threats are applicable to each component.

Secure design patterns are a major exam topic: input validation patterns (allowlist validation at the earliest possible trust boundary; reject invalid input rather than sanitizing it), parameterized query patterns (using prepared statements to prevent SQL injection by separating code from data), output encoding patterns (context-specific encoding to prevent XSS — HTML entity encoding for HTML context, JavaScript escaping for script context, URL encoding for URL parameters), and centralized authentication and session management (a single authentication component rather than multiple ad-hoc implementations). The domain also covers cryptographic design decisions: symmetric vs. asymmetric encryption selection, key length standards, key management architecture, certificate lifecycle management, and the risks of implementing custom cryptographic algorithms (the exam consistently tests that you should never roll your own crypto — use well-audited libraries).

Domain 4: Secure Software Implementation — ~14%

Implementation is where most vulnerabilities are introduced, and this domain tests the coding-level security practices that prevent the most common vulnerability classes. Candidates must understand the mechanisms behind the OWASP Top 10 vulnerabilities at the code level — not just that injection is dangerous, but why a SQL query built from string concatenation is exploitable (the database cannot distinguish between query structure and user-supplied data) and how parameterized queries prevent it (the query structure is fixed at compilation time; user input is always treated as data, never as query syntax). The domain covers cross-site scripting (XSS) prevention (output encoding specific to rendering context), cross-site request forgery (CSRF) prevention (synchronizer token pattern, SameSite cookie attribute), insecure direct object reference prevention (access control checks on every resource access, not just the entry point), and path traversal prevention (canonicalizing file paths before use).

Memory management security is a critical implementation topic: buffer overflow mechanics (writing past the end of a buffer overwrites adjacent memory, potentially overwriting return addresses or function pointers), heap spray techniques, use-after-free vulnerabilities (accessing freed memory that has been reallocated to attacker-controlled data), and integer overflow attacks (arithmetic operations produce values that wrap around the type boundary, bypassing size checks). The domain tests secure coding practices for memory-safe languages (input length validation, bounds checking before array access) and for memory-unsafe languages (using safer library functions like strncpy over strcpy, ASLR/DEP/stack canaries as OS-level mitigations). Static Application Security Testing (SAST) tooling integrates into this domain: candidates must understand how SAST tools analyze code for vulnerability patterns without executing it and the categories of findings they produce (true positives, false positives, and the classes of vulnerabilities they are and are not effective at detecting).

Domain 5: Secure Software Testing — ~14%

Security testing validates that the security controls designed and implemented in earlier phases are actually effective. This domain covers the full spectrum of security testing methodologies and their appropriate application at different SDLC stages. Static Application Security Testing (SAST) analyzes source code or bytecode without executing the application — effective at finding injection flaws, hardcoded credentials, insecure cryptographic API usage, and path traversal vulnerabilities; best integrated into the IDE and CI/CD pipeline for immediate developer feedback. Dynamic Application Security Testing (DAST) tests a running application by sending malicious inputs through its external interfaces — effective at finding authentication bypasses, session management flaws, and runtime configuration errors that SAST cannot detect; best applied against a staging environment before production deployment.

Interactive Application Security Testing (IAST) combines SAST and DAST by instrumenting the application at runtime to observe how data flows through the code during test execution — effective at detecting taint-flow vulnerabilities (tracing attacker-controlled data from input to dangerous sink) with lower false-positive rates than SAST. Penetration testing is a goal-oriented manual assessment where testers attempt to exploit vulnerabilities in a controlled environment — the exam tests the difference between black-box (no prior knowledge), grey-box (partial knowledge), and white-box (full source and architecture knowledge) penetration testing scopes. Fuzzing (automated input mutation to discover crashes and unexpected behavior) is tested in the context of parser security and file format handling. Candidates must also know how to interpret security test results: understanding CVSS scores (Base, Temporal, and Environmental metrics), prioritizing findings by exploitability and business impact, and writing security test cases that can be executed in a regression suite to prevent vulnerability reintroduction.

Domain 6: Secure Software Lifecycle Management — ~11%

This domain covers the organizational and process-level practices that sustain security across the full software lifecycle — the governance layer that ensures security is systematically applied rather than applied inconsistently based on individual developer knowledge. Candidates must understand security in software development methodologies: how secure development practices are adapted for Waterfall (security gates at phase transitions), Agile (security stories in the product backlog, security in the Definition of Done, AppSec engineers as team members or security champions), and DevSecOps (automated security scanning in the CI/CD pipeline, developer-owned security feedback loops). Security training and awareness is a lifecycle management responsibility: CSSLP-level understanding includes how to structure developer security training programs, what secure coding guidelines to establish, and how to measure training effectiveness.

Vulnerability disclosure and management is a key lifecycle topic: responsible disclosure policies (how external researchers should report vulnerabilities; how the organization responds and communicates), coordinated disclosure timelines (the security community norm of giving vendors 90 days to patch before a researcher publishes), and bug bounty programs as a structured mechanism for receiving external security research. The domain also covers software configuration management security: version control for security-critical configurations, change management processes that include security review for significant changes, and the security implications of infrastructure-as-code (IaC) — misconfigurations committed to a git repository are versioned and reproducible, which is both a security risk (secrets in git history) and a security benefit (audit trail of configuration changes).

Domain 7: Secure Software Deployment, Operations, and Maintenance — ~12%

Security does not stop at the code merge. This domain covers the operational security practices that keep software secure after it has been deployed to production. Secure CI/CD pipeline design is a major exam topic: protecting the build environment from compromise (a compromised build server can inject malicious code into every build artifact — the 2020 SolarWinds supply chain attack exploited exactly this vector), signing build artifacts with code signing certificates so consumers can verify artifact integrity, implementing pipeline access controls (least-privilege service accounts for pipeline stages, secrets management for credentials consumed during builds), and separating build, test, and deployment environments with explicit promotion gates.

Patch management and vulnerability remediation tests the operational response to newly discovered vulnerabilities: how to assess applicability (does this CVE affect the versions and configurations we run?), how to prioritize remediation (CVSS severity combined with asset criticality and exploitability in the wild), and how to verify remediation effectiveness (re-testing after patching, monitoring for indicators of compromise). Incident response for software vulnerabilities covers the phases of containment (taking affected systems offline or applying WAF rules to block exploitation while a patch is developed), eradication (root-cause analysis and permanent remediation), and recovery (restoring services with verified-clean artifacts). The domain also covers decommissioning and end-of-life software security: ensuring that retired software does not leave credentials, sensitive data, or exploitable interfaces in production environments after being taken offline.

Domain 8: Secure Software Supply Chain — ~11%

The software supply chain domain has grown from a niche topic to a central CSSLP focus area following high-profile supply chain attacks (SolarWinds 2020, Codecov 2021, Log4Shell 2021) and regulatory mandates requiring software bills of materials (SBOMs). Candidates must understand the components of software supply chain risk: open-source dependencies (most enterprise software now contains hundreds of third-party libraries; each library’s vulnerabilities become the consuming application’s vulnerabilities — the exam tests how to manage transitive dependency risk using dependency scanning tools and SCA platforms), third-party commercial components (SDKs, APIs, proprietary libraries from vendors who may not disclose their security practices or patch timelines promptly), and development tool and CI/CD tool risk (a malicious or compromised build plugin or package registry can inject backdoors into production artifacts).

Software Bill of Materials (SBOM) is a key exam topic in 2026: the NTIA SBOM minimum elements (supplier, component name, component version, other unique identifiers, dependency relationships, SBOM author, and timestamp), the two standard machine-readable SBOM formats (SPDX from the Linux Foundation and CycloneDX from OWASP), and how SBOMs enable vulnerability management by allowing organizations to quickly identify which of their products are affected when a new CVE is published for a widely-used library (like Log4j). Package signing and verification — using cryptographic signatures to ensure that a downloaded package is the same artifact the vendor published — is tested as the primary technical control for preventing compromised package registries from distributing malicious components. The Secure Software Development Framework (SSDF) from NIST SP 800-218 and the Supply Chain Levels for Software Artifacts (SLSA) framework provide the structured maturity model for supply chain security that CSSLP candidates are expected to understand at a conceptual and implementation level.

CSSLP vs CISSP vs SSCP: which ISC2 cert fits your role?

CSSLP — Secure Software Lifecycle Professional

Focus: Software security across the full SDLC — requirements, design, implementation, testing, deployment, supply chain. Target role: AppSec engineer, SSDLC architect, security-focused developer, DevSecOps engineer, software product security manager. Best if: You work in or adjacent to software development and want to prove you can build security in from day one rather than bolt it on at the end.

CISSP — Certified Information Systems Security Professional

Focus: Broad information security management across eight domains (security and risk management, asset security, security architecture, communication and network security, identity management, security assessment, security operations, software development security). Target role: CISO, security manager, security architect, senior security consultant. Best if: You manage security programs, advise on enterprise security strategy, or need the most widely recognized security management credential.

SSCP — Systems Security Certified Practitioner

Focus: Hands-on security operations — access controls, monitoring, incident response, network and communications security, risk identification. Target role: Security analyst, SOC analyst, systems administrator with security responsibilities. Best if: You are earlier in your security career or primarily work in security operations and monitoring rather than software development or security management.

CSSLP and CISSP are complementary for senior security architects who both design software systems and manage the security program around them. The CISSP Domain 8 (Software Development Security) overlaps significantly with CSSLP content, which means CISSP holders pursuing CSSLP will find the exam’s conceptual framework familiar — the CSSLP exam goes considerably deeper in each area. Engineers who hold both credentials are positioned for VP-level product security and CISO roles at software-centric organizations, where the combination of deep SDLC security knowledge (CSSLP) and broad security management capability (CISSP) is the strongest possible credential pairing for leading enterprise security programs.

Key topics to master for CSSLP

STRIDE Threat Modeling Know all six STRIDE categories and how to apply them to a data flow diagram (DFD). Know which DFD element types are associated with which STRIDE threats: processes face Tampering, Repudiation, and DoS; external entities face Spoofing; data stores face Tampering and Information Disclosure; data flows face Tampering and Information Disclosure. Know the difference between a threat (a potential attack) and a vulnerability (a weakness) and a risk (threat × vulnerability × impact).
OWASP Top 10 at Depth Know all ten categories, their root causes (not just their names), and their primary mitigations. Injection requires input validation and parameterized queries. Broken Authentication requires MFA, secure session management, and credential stuffing protection. SSRF requires allowlisting outbound destinations. Supply chain failures require SBOM management and component integrity verification. The exam tests root cause and mitigation, not just category names.
SAST vs DAST vs IAST vs Pen Test Know when to apply each testing method, what vulnerability classes each detects and misses, and how each integrates into the SDLC. SAST integrates in the IDE and CI pipeline; DAST requires a running application; IAST instruments the runtime; pen testing is the final human-driven validation. Know that SAST produces the highest false-positive rate; DAST produces fewer false positives but cannot analyze code paths that are not exercised by test traffic.
Cryptography Selection and Key Management Know the current algorithm recommendations: AES-256 for symmetric encryption, RSA-2048 or ECC-P256+ for asymmetric, SHA-256+ for hashing, bcrypt/Argon2 for password hashing (not SHA-256). Know the difference between encryption (reversible with a key), hashing (one-way), and HMAC (keyed hashing for message authentication). Know that TLS 1.3 is the current standard; TLS 1.0 and 1.1 are deprecated. Never implement custom cryptographic algorithms.
SBOM and Supply Chain Security Know the NTIA minimum SBOM elements, the SPDX and CycloneDX formats, and why SBOMs are mandated by US Executive Order 14028 and the EU Cyber Resilience Act. Know how Software Composition Analysis (SCA) tools scan dependencies against vulnerability databases (NVD, OSV). Know the SLSA framework maturity levels and how code signing (Sigstore, Cosign) prevents compromised registries from serving tampered packages.
Secure CI/CD Pipeline Design Know how to protect the build environment: ephemeral build agents (no persistent state between builds reduces contamination risk), secrets management (credentials injected at runtime from a vault, never stored in repository or environment variables visible to all pipeline stages), artifact signing (every build artifact signed with a private key so downstream consumers can verify integrity), and deployment controls (separation between build, staging, and production environments with explicit human approval gates for production promotion).

Why CSSLP is growing in demand in 2026

Three regulatory and industry forces are driving CSSLP demand to its highest levels since the certification was created. The first is US Executive Order 14028 and NIST SP 800-218: federal agencies and their software suppliers are required to attest to compliance with the NIST Secure Software Development Framework (SSDF), which aligns closely with the CSSLP domain structure. Organizations selling software to the US government need SSDLC practitioners who can implement the SSDF controls — and CSSLP is the most direct credential validation of that capability. Defense contractors, federal systems integrators, and health IT vendors that hold FedRAMP authorizations are actively seeking CSSLP-certified engineers to satisfy these compliance requirements.

The second driver is the EU Cyber Resilience Act (CRA), which entered into force in 2024 and applies to most software products sold in the EU market from 2027 forward. The CRA requires manufacturers of products with digital elements to meet mandatory cybersecurity requirements for the full product lifecycle, including vulnerability handling and security update obligations for the product’s support period. European software companies and multinational organizations with EU product lines are building SSDLC programs to meet CRA requirements, creating demand for CSSLP-certified practitioners who understand how to operationalize lifecycle security requirements at scale.

The third driver is the frequency and cost of software supply chain attacks. The average cost of a data breach in 2026 exceeds $4.5M USD (IBM Cost of a Data Breach Report), and supply chain compromises — where an attacker achieves broad access by compromising a trusted dependency rather than a direct target — are among the most costly and hardest-to-detect breach types. Organizations that deploy CSSLP-certified practitioners to manage software supply chain risk — inventorying dependencies, monitoring for newly disclosed CVEs, enforcing component signing and verification — are materially reducing their exposure to this attack class. Security-conscious boards and executive teams are increasingly mandating these programs, creating senior-level demand for practitioners with the credential that validates supply chain security expertise.

CSSLP is the certification that proves you ship software that is secure by design, not by patch — the practitioner credential for the DevSecOps era, where security is everyone’s responsibility and the SDLC is the primary control plane.

Salary impact and career outcomes

CSSLP holders command premium compensation in 2026 because the supply of engineers with both deep software development knowledge and formal security expertise remains well below demand. Application security engineers with CSSLP earn median base salaries of $120,000 to $145,000 in North American markets. Senior AppSec architects and Product Security leads who hold CSSLP alongside CISSP reach $155,000 to $180,000 at large technology companies and financial institutions. Principal-level roles (Principal Security Engineer, Staff AppSec Engineer) with full-stack secure development responsibility and CSSLP credentials are the highest-paying non-management security positions, reaching $185,000 to $220,000 total compensation at top-tier technology companies.

The job titles most associated with CSSLP in 2026 postings include: Application Security Engineer, Product Security Engineer, DevSecOps Engineer, Secure Software Development Architect, Staff Security Engineer, Principal AppSec Engineer, and Software Security Consultant. Financial services organizations (investment banks, payment networks, insurance companies with digital products) and defense and intelligence contractors represent the highest-paying markets, where regulatory requirements for secure software development are strictest and the business impact of a software vulnerability is most severe. Technology companies building developer tools, cloud platforms, and security products are the second-largest market, followed by healthcare technology companies navigating HIPAA and FDA medical device cybersecurity guidance.

Who should pursue CSSLP in 2026

Senior Developers Moving into AppSec Experienced software engineers who want to transition into application security engineering or security architecture. CSSLP validates the SSDLC depth that distinguishes a senior developer who has informally learned security on the job from a credentialed AppSec professional who can lead security programs, conduct design reviews, and implement security testing pipelines.
AppSec Engineers Seeking Advancement Security engineers already working in application security who want to move into senior or principal roles. CSSLP is increasingly listed as a requirement or strong preference for senior AppSec positions at large organizations, and the eight-domain breadth of the exam validates the full-lifecycle perspective that distinguishes a senior practitioner from a specialist in one area.
DevSecOps Practitioners Engineers building and operating secure CI/CD pipelines, integrating SAST/DAST tooling, managing secrets and artifact signing, and implementing developer security feedback loops. Domain 7 (Deployment, Operations, Maintenance) and Domain 8 (Supply Chain) align directly with DevSecOps responsibilities, and the full exam validates the SDLC security breadth that distinguishes mature DevSecOps programs from security theater.
CISSP Holders Adding Software Depth Security professionals with CISSP who find that the CISSP Domain 8 (Software Development Security) represents a significant portion of their work and want deeper validation in that area. The CSSLP exam goes five to ten times deeper than the CISSP Software Development Security domain in every topic area — it is the natural credential for security architects whose primary domain is software security rather than general information security management.
Product Security Managers Security practitioners who own product security programs at software companies — running the security review process, owning the vulnerability disclosure program, managing the relationship with external security researchers, and reporting software security risk to executive leadership. CSSLP validates the technical depth to credibly manage these programs and communicate risk in engineering terms.
Federal Contractors and GovTech Engineers Software engineers and security practitioners at organizations that sell software to US federal agencies, where NIST SP 800-218 (SSDF) compliance attestations are required and CSSLP is the most recognized credential for demonstrating the practitioner-level capability to implement those requirements. FedRAMP-authorized SaaS companies, defense contractors, and federal system integrators are all active CSSLP hiring markets.

Study approach and resources

ISC2 publishes the official CSSLP Certification Exam Outline (free download from the ISC2 website), which lists every exam objective, sub-objective, and example topic for all eight domains. Treating this document as a study checklist — marking each sub-objective when you can explain it, give an example, and name the controls that address it — is the most efficient preparation strategy. The official CSSLP Study Guide published by ISC2 covers all eight domains in depth and is the primary reference material most candidates use as their study backbone.

For practical application, candidates should work through the OWASP Testing Guide (a comprehensive resource for security testing techniques that aligns directly with Domain 5), the NIST SSDF (SP 800-218) full document (essential for Domains 6, 7, and 8), and the OWASP Software Assurance Maturity Model (SAMM) (useful for understanding how to mature a software security program across the practices that map to CSSLP domains). Hands-on practice should include running SAST tools (Semgrep, SonarQube, CodeQL) against intentionally vulnerable applications (DVWA, WebGoat, Juice Shop), performing basic DAST scanning with OWASP ZAP, and building a simple CI/CD pipeline with security gates in GitHub Actions or GitLab CI.

The most commonly missed CSSLP exam areas are supply chain security specifics (candidates know that supply chain risk exists but cannot articulate the NTIA SBOM minimum elements, the SPDX vs. CycloneDX format differences, or the SLSA maturity levels), cryptography selection trade-offs (candidates know AES and RSA but cannot articulate why Argon2 is preferred over bcrypt for new deployments, or why TLS 1.2 with weak cipher suites is inadequate even though TLS 1.2 itself is not deprecated), and privacy-by-design requirements engineering (candidates understand GDPR at a high level but cannot translate data minimization and purpose limitation into specific software requirements). Allocating focused study time to these three areas addresses the gaps responsible for most near-miss failures on the exam.

ISC2 Official CSSLP Resources — free exam outline and candidate resources

ISC2’s candidate information page for CSSLP includes the free official exam outline, the candidate information bulletin with exam policies and procedures, and links to the official study guide and ISC2-authorized training courses. The ISC2 Online Self-Paced Training for CSSLP covers all eight domains with video lectures, practice questions, and case studies. ISC2 also offers instructor-led virtual training for candidates who benefit from structured classroom learning and live Q&A with an authorized instructor. Both formats include access to ISC2’s official practice question bank, which is the most accurate predictor of the types of scenario-based questions that appear on the actual exam.

Practice CSSLP questions free on CertQuests.

CSSLP Practice Questions →