Certified Information Systems Security Professional

Certified Information Systems Security Professional (CISSP)

When to Use

• Structure CISSP/CBK study — domain map, manager mindset, practice workflow (no copyrighted items)
• Design security programs using CBK domains — policies, standards, procedures, ownership
• Frame risk management — threats, vulnerabilities, impact, treatment, residual risk
• Select and justify controls — administrative, technical, physical; defense in depth
• Support audit and assessment narratives — scope, sampling, findings, management responses
• Align work to NIST CSF / ISO 27001 concepts at program level (not control-by-control automation)
• Explain IAM, network security, crypto, and SDLC at architecture and governance depth
• Translate CBK topics to organizational roles — what leaders decide vs technicians execute

When NOT to Use

• SOC alert triage, shift handoffs, or playbook execution → soc-analyst
• Declared incident command, containment, forensics → incident-responder
• Execute penetration tests or exploit chains → penetration-tester
• Cloud-only attestations, CSPM evidence, residency packages → cloud-compliance-specialist
• Board-only strategy, appetite, crisis comms without CBK/program lens → chief-information-security-officer
• Deploy SIEM rules, hardening, IAM/terraform, EDR → information-security-engineer
• GRC program scope, gap assessments, audit prep packs → compliance-specialist
• Evidence automation from IdP/CI/CD/CSPM → compliance-engineer
• Enterprise reference architecture and zero-trust standards → enterprise-security-architect
• Risk registers, FAIR scoring, treatment matrices → security-risk-analyst
• Broad security strategy without CBK or certification framing → cybersecurity
• Legal interpretation, contracts, or regulatory filings → legal counsel

Related skills

Core Workflows

1. Scope and CBK orientation

Clarify whether the ask is exam prep, program design, audit narrative, or control selection. Map the topic to CBK domains and the manager vs technician boundary.

See `references/cissp_scope_and_cbk_overview.md`.

2. Security and risk management (Domain 1)

Governance, policies, risk treatment, BCP/DRP themes, legal/regulatory concepts at program level, and security awareness.

See `references/security_and_risk_management.md`.

3. Asset security and architecture (Domains 2–3)

Data classification, handling, retention; secure design principles, models, and evaluation criteria.

See `references/asset_security_and_architecture.md`.

4. Network, IAM, and assessment (Domains 4–6)

Secure communications, identity lifecycle, access models, and assessment types (audit, test, evaluate).

See `references/network_iam_and_assessment.md`.

5. Security operations and SDLC (Domains 7–8)

Monitoring, IR program elements, DR operations; secure SDLC, supply chain, and software assurance.

See `references/security_operations_and_sdlc.md`.

6. Apply CBK to organizational practice

Policies, NIST/ISO alignment, governance cadence, study workflow, and handoffs to specialist skills.

See `references/applying_cissp_to_programs.md`.

Outputs

• Domain study map — topic checklist per CBK domain with weak-area focus
• Program alignment brief — how initiatives map to domains and control families
• Policy/governance outline — hierarchy (policy → standard → procedure), owners, review cadence
• Risk and control narrative — threat, control objective, implementation type, residual risk
• Audit support memo — scope, population, sampling approach, finding severity framing
• Role handoff table — CISSP-level decision vs engineering/GRC/IR execution owners

Principles

• Manager mindset — breadth across domains; delegate depth to specialists
• Defense in depth — layer administrative, technical, and physical controls
• Risk-based prioritization — tie controls and spend to likelihood and impact
• No exam brain dumps — teach concepts and structure; do not reproduce copyrighted items
• Complement, not replace — use CISO/GRC/engineering skills for their execution lanes

When to load references

• CBK domains and exam context → references/cissp_scope_and_cbk_overview.md
• Domain 1 → references/security_and_risk_management.md
• Domains 2–3 → references/asset_security_and_architecture.md
• Domains 4–6 → references/network_iam_and_assessment.md
• Domains 7–8 → references/security_operations_and_sdlc.md
• Programs, frameworks, study workflow → references/applying_cissp_to_programs.md

Applying CISSP to organizational programs

Table of contents

1. From CBK to operating model 2. Framework alignment 3. Policy and governance cadence 4. Study and exam prep workflow 5. Manager vs technician in practice 6. Deliverable templates

From CBK to operating model

Map CBK domains to functions your organization actually runs:

Produce a single-page domain RACI so initiatives do not duplicate ownership.

Framework alignment

Use frameworks as structured control sets, not as substitutes for risk thinking.

Mapping practice: For each in-scope control, document objective, implementing control, owner, evidence, and CBK domain(s). Deep GRC execution: compliance-specialist.

Policy and governance cadence

Exception process: Requestor, risk assessment, approver authority, expiry, compensating controls—CISSP designs the process; GRC tracks.

Study and exam prep workflow

Educational workflow only—verify all requirements with official (ISC)² resources.

1. Baseline — self-assess each of eight domains (weak / medium / strong) 2. Schedule — allocate more time to weak domains; maintain breadth 3. Study sources — official outline, authorized materials, legitimate practice questions 4. Active recall — explain concepts aloud; teach manager-judgment scenarios 5. Practice exams — analyze why answers are correct; adjust study plan 6. Ethics — review Code of Ethics scenarios 7. Exam week — rest, logistics, ID requirements per candidate handbook

Prohibited: brain dumps, shared exam items, or any copyright violation—refuse such requests.

Manager vs technician in practice

Deliverable templates

Program alignment brief (outline):

• Business context and regulatory drivers
• Domain heat map (maturity or gap)
• Top 5 risks and planned treatments
• Initiatives by quarter with owners
• Dependencies on architecture and GRC

Audit support memo (outline):

• Control objective and CBK/domain mapping
• Population and sampling approach
• Evidence types and systems of record
• Known exceptions and compensating controls
• Prior finding remediation status

Study plan (outline):

• Domain weights from self-assessment
• Weekly topics and practice question targets
• Review dates and accountability partner

Hand technical evidence collection and control deployment to compliance-engineer and information-security-engineer after CISSP-level framing is agreed.

Asset Security and Security Architecture (Domains 2–3)

Table of contents

1. Asset Security (Domain 2) 2. Security Architecture and Engineering (Domain 3) 3. Cryptography themes 4. Physical security themes 5. Integration across domains

Asset Security (Domain 2)

Information lifecycle: Create → use → store → share → archive → destroy.

Data states: Data at rest, in transit, in use—controls differ (encryption, DLP, access, monitoring).

Privacy-enhancing techniques (concepts): minimization, pseudonymization, tokenization—implement with engineering and legal alignment.

Asset inventory: Hardware, software, data, people, services—feeds risk assessment and CMDB; automation is information-security-engineer / GRC evidence work.

Security Architecture and Engineering (Domain 3)

Secure design principles (representative):

• Least privilege, separation of duties, defense in depth
• Fail secure, privacy by design, simplicity
• Zero trust (verify explicitly, least privilege, assume breach) as architectural direction

Security models (know conceptually):

Evaluation criteria: TCSEC, ITSEC, Common Criteria (EAL)—understand assurance and target of evaluation for procurement, not memorization of obsolete levels alone.

Vulnerability categories (architecture lens): design flaws, implementation bugs, operational misconfigurations—pair with Domain 6 testing programs.

Cryptography themes

Common applications: TLS, IPsec, S/MIME, disk encryption, code signing. Select algorithms and key lengths per organizational crypto standards and current guidance—implementation detail belongs with engineers.

Physical security themes

• Site selection, facility design, perimeter controls
• Access badges, mantraps, CCTV, guards
• Environmental controls (HVAC, fire, power)
• Media handling and secure destruction in datacenters

Coordinate with facilities and datacenter teams; CBK framing sets requirements, operations executes.

Integration across domains

When designing systems, produce data flow diagrams and trust boundaries—hand detailed patterns to enterprise-security-architect.

CISSP scope and CBK overview

Table of contents

1. Role boundary 2. The eight CBK domains 3. Exam context (high level) 4. Manager vs technician mindset 5. Handoffs

Role boundary

This skill teaches how security leaders think across the CBK—not how to run a single tool or shift.

The eight CBK domains

Use domain numbers when mapping study plans, gap analyses, and program roadmaps.

Exam context (high level)

• Audience: Experienced practitioners; exam tests breadth and judgment across domains
• Format (verify current (ISC)² materials): Computerized adaptive testing; mix of scenario and knowledge items
• Ethics: Professional responsibility and (ISC)² Code of Ethics themes appear in study and practice
• Preparation: Official outlines, authorized training, practice questions from legitimate sources only
• Do not: Request or provide verbatim exam items, brain dumps, or stolen content

Educational references here explain concepts and structure—not memorization of proprietary items.

Manager vs technician mindset

When a question needs packet captures, exploit PoCs, or Terraform modules, route to engineering or offensive skills.

Handoffs

Network, IAM, and Security Assessment (Domains 4–6)

Table of contents

1. Communication and Network Security (Domain 4) 2. Identity and Access Management (Domain 5) 3. Security Assessment and Testing (Domain 6) 4. Cross-domain control patterns

Communication and Network Security (Domain 4)

OSI and TCP/IP — map security controls to layers (e.g., switching vs routing, TLS at application layer).

Attack classes (recognize for governance and assessment scope): spoofing, tampering, repudiation, disclosure, DoS, elevation of privilege (STRIDE complements CBK).

Secure protocols: Prefer modern TLS versions; deprecate weak ciphers; understand IPsec modes (transport vs tunnel) at decision level.

Cloud networking: Shared responsibility—customer configures security groups, NACLs, private endpoints; provider secures hypervisor and physical layer.

Identity and Access Management (Domain 5)

Identity lifecycle: Provisioning → review → modification → suspension → deprovisioning.

Access control models:

• MAC — labels enforced by system
• DAC — owner grants permissions
• RBAC — roles aggregate permissions
• ABAC — attributes (context-aware)

IAM program elements: SoD, recertification campaigns, privileged access reviews, passwordless/MFA policy. Implementation: information-security-engineer and IdP teams.

Security Assessment and Testing (Domain 6)

Testing program governance:

• Rules of engagement, scope, production constraints
• Remediation SLAs by severity
• Retest and exception tracking
• Metrics: mean time to remediate, recurring findings

Audit support (CISSP lens): define population, sampling, control objective, test procedure, evidence type—compliance-specialist owns pack assembly; compliance-engineer automates collection.

False positives / negatives: Risk to resource allocation; tune processes, not only tools.

Cross-domain control patterns

Route active exploitation and tool-specific runbooks to penetration-tester; route SOC tuning to soc-analyst and defensive-security-analyst.

Security and Risk Management (Domain 1)

Table of contents

1. Governance and policies 2. Risk management 3. Compliance and legal themes 4. Business continuity and resilience 5. Awareness and culture 6. Exam and program hooks

Governance and policies

Security governance aligns security with business objectives through defined roles, accountability, and oversight.

Due care vs due diligence: Due care is reasonable action to protect assets; due diligence is ongoing verification that care is effective (audits, reviews, metrics).

Security committees (steering, risk, change advisory) document decisions, exceptions, and prioritization—CISSP-level work defines charter and cadence; specialists run meetings and trackers.

Risk management

Risk management process (typical): Identify assets → assess threats/vulnerabilities → analyze impact/likelihood → evaluate options → select treatment → monitor.

Quantitative vs qualitative: Quantitative uses numbers (ALE, SLE, ARO); qualitative uses scales and matrices. Programs often blend both for prioritization.

Supply chain risk: Third-party access, software dependencies, and fourth-party concentration belong in Domain 1 framing—execution spans vendor management and engineering skills.

Compliance and legal themes

At CBK depth, understand categories of obligations—not legal advice:

• Privacy and data protection principles (purpose limitation, minimization, rights)
• Intellectual property and licensing impacts on security tooling
• Investigative limitations and evidence handling concepts
• Import/export and cryptography controls (organizational policy triggers legal review)

Map obligations to control objectives and hand detailed interpretation to legal counsel.

Business continuity and resilience

MTD, RTO, RPO, WRT — align recovery targets with business impact tiers. CISSP work sets tiers and tests; bcm-disaster-recovery-specialist deepens exercise design and immutability patterns.

Awareness and culture

• Role-based training tied to data classification and job function
• Phishing simulations and metrics (report rate, repeat offenders)
• Metrics: completion, incidents tied to human factors, culture surveys
• Align awareness with policy violations and disciplinary process (HR/Legal)

Exam and program hooks

Study Domain 1 for: governance models (e.g., board oversight), policy hierarchy, risk formulas at concept level, ethics scenarios, and BCP/DRP vocabulary.

In organizations: use Domain 1 to draft security charter, risk appetite alignment (with security-risk-analyst), and annual program objectives before control implementation backlogs.

Security Operations and Software Development Security (Domains 7–8)

Table of contents

1. Security Operations (Domain 7) 2. Software Development Security (Domain 8) 3. Operations vs development handoffs

Security Operations (Domain 7)

Foundational capabilities (program view):

Investigation types: Administrative (policy), civil, criminal—different evidence standards; coordinate with Legal.

Malware response (program): isolation, analysis decision, eradication, communication—technical steps belong to IR teams.

Metrics (examples): MTTD, MTTR, incident volume by category, patch SLA compliance, backup success rate.

Do not conflate: CISSP describes what the SOC/IR program must achieve; soc-analyst and incident-responder run shifts and playbooks.

Software Development Security (Domain 8)

Secure SDLC phases (generic):

1. Requirements — security user stories, abuse cases 2. Design — threat modeling, security architecture review 3. Implementation — secure coding standards, secrets management 4. Verification — SAST, DAST, SCA, pen test 5. Release — signing, SBOM, deployment gates 6. Operations — monitoring, vulnerability response, deprecation

Common vulnerability classes (awareness level): injection, broken auth, sensitive data exposure, XXE, broken access control, misconfiguration, XSS, insecure deserialization, known vulnerable components, insufficient logging.

Supply chain: Third-party libraries, build pipeline integrity, artifact signing, dependency pinning—align with organizational SSDF / SAMM maturity goals.

API and microservices: Authentication, rate limiting, schema validation, service mesh identity—architecture detail: enterprise-security-architect.

DevSecOps: Shift-left testing, pipeline gates, developer training—automation: engineering and compliance-engineer for evidence.

Operations vs development handoffs

Change advisory board (CAB): Security reviews emergency changes and high-risk deployments—CISSP defines criteria; operations enforces.