Domain 1 accounts for 16 percent of the current CISSP exam outline, the largest average weight of the eight domains. It establishes how an organization decides what security should accomplish, who is accountable, which obligations apply, how risk is evaluated, and how people are prepared to follow the program.
The domain reaches far beyond a risk register. A scenario may begin with a supplier, employee, policy, investigation, privacy requirement, business process, or artificial intelligence service. Follow the chain of authority and evidence: identify the requirement, determine ownership, assess the risk, choose a treatment, document the decision, implement controls, and monitor the result.
1. Domain 1 map
The official outline divides Security and Risk Management into twelve objectives:
| Objective | Main focus | Questions to ask |
|---|---|---|
| 1.1 | Professional ethics | Which action protects the public, serves the principal responsibly, and preserves professional integrity? |
| 1.2 | Security concepts | Which security property or assurance goal is required? |
| 1.3 | Governance | How does security align with strategy, authority, accountability, frameworks, due care, and due diligence? |
| 1.4 | Legal, regulatory, and compliance issues | Which jurisdiction, contract, standard, privacy duty, license, or regulatory obligation applies? |
| 1.5 | Investigation requirements | What authority, process, evidence standard, and reporting path fit the investigation? |
| 1.6 | Policy hierarchy | Which document sets direction, mandatory requirements, repeatable steps, or recommended practice? |
| 1.7 | Business continuity | Which business processes, dependencies, impacts, recovery needs, and resilience priorities matter? |
| 1.8 | Personnel security | What controls belong before, during, and after employment or third-party access? |
| 1.9 | Risk management | How is risk identified, analyzed, prioritized, treated, assigned, monitored, and reported? |
| 1.10 | Threat modeling | Which assets, trust boundaries, threats, attack paths, and mitigations should be examined? |
| 1.11 | Supply-chain risk | How will the organization assess suppliers, define requirements, monitor dependencies, and prepare alternatives? |
| 1.12 | Awareness, education, and training | Which audience, behavior, skill, delivery method, and measure of effectiveness fit the need? |
One scenario can touch several objectives. Acquiring an artificial intelligence service may involve ethics, privacy, contracts, supplier due diligence, risk assessment, data governance, continuity planning, security requirements, and role-based learning. The objective numbers help organize study, but the real decision crosses organizational boundaries.
2. Use the right decision order
CISSP questions often reward process and authority. A technical control may be useful, but it can still be the wrong first action.
A practical decision sequence is:
- Identify the business objective and affected stakeholders. Clarify the service, mission, people, data, safety, and obligations at risk.
- Determine authority and ownership. Identify the business owner, risk owner, data owner, system owner, or other accountable role.
- Confirm requirements. Review law, regulation, contract, policy, classification, architecture, and risk appetite.
- Assess the risk. Describe threats, vulnerabilities, likelihood, impact, existing controls, uncertainty, and dependencies.
- Present treatment options. Compare avoidance, mitigation, transfer, and acceptance with cost, feasibility, and residual risk.
- Obtain approval at the proper level. Security staff provide analysis and recommendations. The accountable owner makes the business-risk decision.
- Implement and document controls. Assign responsibilities, define measurable requirements, and retain evidence.
- Monitor and improve. Reassess after changes, incidents, new threats, supplier events, audit findings, and changes in business priorities.
A question may begin at any point in this sequence. Read for what has already happened. If requirements and risk have been assessed, returning to the first step may be unnecessary. If the organization has not identified the affected data or owner, selecting a product is premature.
3. Professional ethics and security principles
Ethical duties guide technical authority
Security professionals can access sensitive information, interrupt services, investigate people, influence risk decisions, and recommend expensive controls. Ethical obligations help keep that authority aligned with public safety, lawful behavior, honest service, and the health of the profession.
The ISC2 ethics framework places duties toward society and the common good above narrower interests. It also expects professionals to act honorably, provide competent service to those they represent, and support the profession. When duties appear to conflict, do not quietly choose the option that is easiest for the employer or the security team. Identify the stakeholders, applicable duties, potential harm, authority, and escalation path.
Examples:
- A manager asks an analyst to hide a material finding from a customer. The analyst should preserve integrity, follow reporting obligations, and use an appropriate escalation path.
- An investigation exposes unrelated personal information. The team should limit collection and access to what the authorized purpose requires.
- A penetration tester discovers a serious issue outside the agreed scope. The tester should preserve evidence and follow the rules of engagement rather than expanding activity without authorization.
- A security control creates a safety hazard. Protecting systems does not justify ignoring the risk to people.
Confidentiality, integrity, availability, authenticity, and nonrepudiation
The current outline names five pillars of information security:
| Property | Purpose | Example evidence |
|---|---|---|
| Confidentiality | Prevents unauthorized disclosure. | Access controls, encryption, data masking, and restricted distribution. |
| Integrity | Protects accuracy, completeness, and authorized change. | Hashes, digital signatures, change controls, validation, and reconciliation. |
| Availability | Keeps information and services accessible when required. | Redundancy, capacity, backups, failover, maintenance, and recovery testing. |
| Authenticity | Provides confidence that an identity, message, system, or object is genuine. | Identity proofing, certificates, signed code, and trusted provenance. |
| Nonrepudiation | Supports proof that an action or communication occurred and is attributable to a party. | Digital signatures, protected logs, timestamps, and controlled audit trails. |
A control can support several properties. A digital signature can provide integrity, authenticity, and evidence useful for nonrepudiation. It does not provide confidentiality unless the content is also encrypted.
4. Security governance
Governance establishes direction, accountability, oversight, and alignment with organizational objectives. Management plans and executes work within that direction. The terms overlap in conversation, but the distinction matters on the exam.
Governance and management
| Area | Governance focus | Management focus |
|---|---|---|
| Direction | Sets priorities, principles, risk expectations, and accountability. | Turns direction into plans, projects, controls, and daily operations. |
| Authority | Assigns decision rights and oversight responsibilities. | Uses delegated authority to execute and coordinate work. |
| Measurement | Reviews whether outcomes support organizational objectives. | Tracks performance, resources, schedules, findings, and corrective actions. |
| Risk | Defines appetite and oversight expectations. | Assesses, treats, monitors, and reports risk within that direction. |
Roles and responsibilities
Titles vary, so focus on the responsibility:
| Role | Typical responsibility |
|---|---|
| Board or governing body | Provides oversight, approves direction, and holds leadership accountable for material organizational risk. |
| Senior management | Translates direction into organizational priorities, resources, accountability, and risk decisions. |
| Security leadership | Advises leadership, coordinates the security program, reports risk, and manages security capabilities. |
| Business or mission owner | Owns the business outcome and accepts risk within delegated authority. |
| System owner | Ensures a system meets business and security requirements across its lifecycle. |
| Data owner | Defines classification, access, handling, retention, and protection requirements for information. |
| Custodian | Implements and operates controls according to the owner's requirements. |
| Control owner | Maintains a control, its evidence, and its operating effectiveness. |
| Risk owner | Has authority and accountability for a specific risk and its treatment. |
| Assessor or auditor | Evaluates requirements, controls, evidence, and results with the required degree of independence. |
A chief information security officer can advise that a risk should be accepted. The person with the appropriate business authority accepts it. A custodian can configure access controls. The data owner defines who should have access.
Security frameworks and architectures
The outline names several examples. They solve different problems:
| Framework or approach | Useful purpose |
|---|---|
| NIST Cybersecurity Framework | Organizes cybersecurity outcomes and supports communication about current and target risk-management practices. |
| NIST Risk Management Framework | Provides a lifecycle process for preparing, categorizing, selecting, implementing, assessing, authorizing, and monitoring controls. |
| ISO/IEC 27001 family | Supports an information security management system with risk-based requirements and continual improvement. |
| COBIT | Supports governance and management of enterprise information and technology. |
| SABSA | Connects business requirements to layered security architecture. |
| PCI DSS | Defines contractual industry requirements for protecting payment-card account data. |
| FedRAMP | Provides a standardized U.S. federal approach to assessing, authorizing, and continuously monitoring cloud services. |
Do not assume that selecting a framework completes governance. The organization still needs scope, ownership, tailored requirements, implementation, evidence, review, and improvement.
Due care and due diligence
Due care is the responsibility to take reasonable and appropriate steps to protect people, assets, and interests from foreseeable harm. It is demonstrated through the safeguards and decisions an organization actually puts into practice.
Due diligence is the ongoing process of investigating, verifying, monitoring, and documenting whether those safeguards remain appropriate and effective. It is demonstrated through assessments, reviews, testing, supplier checks, and corrective actions.
Buying a security tool can demonstrate neither by itself. The organization must select an appropriate control, configure it, operate it, monitor it, respond to findings, and adjust it as conditions change.
5. Legal, regulatory, compliance, and investigation requirements
CISSP is global, and legal requirements vary by jurisdiction. The exam expects candidates to recognize the type of obligation and the need for qualified legal guidance, not to practice law from memory.
Sources of requirements
| Source | How it applies | Example question |
|---|---|---|
| Law | Created by a legislative authority and enforced within its jurisdiction. | Which legal duty applies to a breach, surveillance activity, or protected information? |
| Regulation | Detailed requirements issued under legal authority by a regulator. | Which evidence, control, or notification is required by the regulator? |
| Contract | Creates obligations among parties, including security, privacy, audit, notification, and service requirements. | Which requirement should be written into the agreement before service begins? |
| Industry standard | May be voluntary, contractually required, or tied to participation in an industry ecosystem. | What proof is needed to demonstrate conformity or maintain eligibility? |
| Policy | Creates an internal organizational requirement within the authority that approved it. | Which employee, system, or supplier action violates the organization's stated rule? |
Important issue areas include cybercrime, breach obligations, privacy, intellectual property, licensing, import and export restrictions, contractual commitments, and transborder data flows. A data transfer can be lawful in one location and restricted in another. A software license can limit copying, reverse engineering, geography, or usage. A breach can trigger several contractual and regulatory timelines.
The appropriate response is usually to identify the issue early, preserve facts, follow approved procedures, and involve legal, privacy, compliance, human resources, law enforcement, regulators, or other stakeholders as required.
Investigation types
| Investigation | Typical purpose | Important considerations |
|---|---|---|
| Administrative | Examines policy, workplace, or organizational misconduct. | Employment rules, privacy, human resources, internal authority, consistency, and documentation. |
| Criminal | Supports potential prosecution for an alleged crime. | Lawful authority, evidence handling, chain of custody, legal standards, and coordination with law enforcement. |
| Civil | Supports disputes among private parties or claims for remedies. | Preservation duties, discovery, legal holds, relevance, and counsel direction. |
| Regulatory | Determines compliance with requirements enforced by a regulator. | Jurisdiction, reporting duties, required evidence, cooperation, and remediation. |
| Industry or contractual | Determines conformity with a standard, agreement, or participation requirement. | Scope, assessor independence, evidence, reporting, contractual remedies, and follow-up. |
Do not begin an investigation by collecting everything available. Confirm authority, scope, purpose, preservation requirements, privacy limits, and the people who should direct the work. Excessive collection can create legal, privacy, operational, and evidence-handling problems.
6. Policy, standards, procedures, guidelines, and baselines
Governance documents differ by purpose and authority:
| Document | Purpose | Example |
|---|---|---|
| Policy | States management direction and required outcomes. | Sensitive information must be classified and protected according to business and legal requirements. |
| Standard | Defines a mandatory, measurable requirement that supports policy. | Administrative access must use phishing-resistant multifactor authentication. |
| Procedure | Lists the approved steps for completing a repeatable task. | Disable accounts, recover devices, transfer ownership, and record approval during termination. |
| Guideline | Provides recommended practice when flexibility and judgment are appropriate. | Prefer approved collaboration tools when sharing large internal files. |
| Baseline | Defines a minimum configuration or control set for a class of systems or assets. | All managed laptops receive the approved operating-system hardening baseline. |
A policy should remain stable enough to guide decisions through routine technology changes. Standards, baselines, and procedures contain more implementation detail and usually change more often.
A useful document lifecycle includes:
- Named ownership
- Stakeholder review
- Approval by the proper authority
- Version control and effective date
- Communication and acknowledgement where appropriate
- Training for affected roles
- Exception handling
- Monitoring and enforcement
- Periodic and event-driven review
- Retirement of obsolete versions
An exception should identify the requirement, scope, business reason, risk, compensating controls, owner, approver, expiration date, and review conditions. A permanent undocumented exception is a control failure disguised as flexibility.
7. Business continuity requirements
Business Continuity (BC) keeps priority business functions operating through disruption. Disaster Recovery (DR) restores technology and facilities needed to support those functions. Disaster recovery is part of the broader continuity effort.
Business impact analysis
A Business Impact Analysis (BIA) identifies priority processes, the effects of disruption, recovery needs, and dependencies. It should begin with business functions rather than the inventory of servers.
Questions include:
- Which services must continue or resume first?
- How does impact increase over time?
- Which people, facilities, information, systems, suppliers, utilities, and communications are required?
- Which manual workarounds are possible, and for how long?
- Which legal, contractual, safety, or customer obligations apply?
- What capacity is required during recovery?
Continuity and recovery measurements
| Measure | Meaning | Question it answers |
|---|---|---|
| Maximum tolerable downtime | The longest disruption the organization can tolerate before consequences become unacceptable. | How long can the business process remain unavailable? |
| Recovery Time Objective (RTO) | The targeted time to restore a service or capability after disruption. | How quickly should this be restored? |
| Recovery Point Objective (RPO) | The maximum acceptable amount of data loss measured in time. | How far back may the recovered data be? |
| Work Recovery Time | The time needed after technology restoration to validate, reconcile, and resume the business process. | How long will the business need after systems return? |
The RTO plus the work recovery time should fit inside the maximum tolerable downtime. An RPO does not describe how quickly a system returns. It describes acceptable data loss.
Use the Recovery Metrics Quick Reference for focused comparisons among RTO, RPO, Mean Time to Repair (MTTR), and Mean Time Between Failures (MTBF).
External dependencies
A recovery plan fails when it restores the application but ignores identity services, telecommunications, power, cloud regions, suppliers, payment processors, certificate services, staffing, or physical access.
Document dependencies and recovery assumptions. Confirm that a supplier's commitment supports the organization's objective. A four-hour internal RTO is not credible when the only provider contract promises restoration within two business days.
8. Personnel security
Personnel security manages risk before access is granted, while responsibilities change, and when the relationship ends. It applies to employees, contractors, consultants, vendors, temporary workers, and other third parties.
Before access
- Define role requirements and conflicts of interest.
- Perform screening that is lawful, proportionate, and relevant to the role.
- Use employment, confidentiality, acceptable-use, intellectual-property, and conduct agreements as appropriate.
- Establish the sponsor, manager, owner, duration, and scope of third-party access.
- Complete required training and acknowledgement before sensitive access is activated.
During employment or engagement
- Apply least privilege and need to know.
- Separate incompatible duties.
- Review access after transfers, promotions, extended leave, and role changes.
- Use job rotation and mandatory leave where they help expose concealed activity or reduce dependency on one person.
- Monitor privileged activity according to policy and law.
- Provide role-based training and clear reporting channels.
- Enforce policy consistently and document exceptions.
Termination and offboarding
Termination planning should be coordinated and timed according to risk. Common actions include:
- Disable physical and logical access.
- Revoke sessions, credentials, tokens, keys, certificates, and remote access.
- Recover devices, badges, documents, and other assets.
- Transfer data, records, approvals, and ownership.
- Preserve information subject to retention or legal hold.
- Remind the departing person of continuing obligations.
- Notify affected teams and suppliers.
- Review unusual activity when risk warrants it.
Friendly departures still require complete offboarding. Hostile departures may require tighter timing, monitoring, escort, and coordination, but actions should remain lawful and approved.
9. Risk management
Risk management gives decision-makers a structured way to compare uncertainty, potential harm, business value, and available treatments.
Core terms
| Term | Meaning |
|---|---|
| Asset | Something the organization values, including people, information, systems, services, facilities, reputation, and mission outcomes. |
| Threat | A circumstance or event with the potential to cause harm. |
| Vulnerability | A weakness or condition that can be exploited or triggered. |
| Likelihood | The chance that the relevant threat event will occur and produce harm. |
| Impact | The consequence to operations, assets, people, other organizations, or society. |
| Inherent risk | Risk before considering the effect of controls. |
| Residual risk | Risk remaining after controls and other treatments are considered. |
| Risk appetite | The amount of possible loss, harm, disruption, or uncertainty an organization is willing to accept while pursuing its goals. |
| Risk tolerance | The limit for how much loss, harm, delay, or disruption is acceptable in one area. For example, an organization may accept some downtime but set a maximum of two hours. |
| Risk capacity | The maximum risk the organization can absorb without threatening its viability or obligations. |
Risk appetite sets the broad boundary. Risk tolerance turns that boundary into measurable limits.
Qualitative and quantitative analysis
Qualitative analysis uses ordered categories such as low, medium, and high. It is practical when reliable numeric data is limited and supports prioritization across many risks. The rating criteria should be defined so different assessors do not apply the labels arbitrarily.
Quantitative analysis uses numeric estimates. Common formulas include:
- Single Loss Expectancy (SLE) = Asset Value (AV) × Exposure Factor (EF)
- Annualized Loss Expectancy (ALE) = SLE × Annualized Rate of Occurrence (ARO)
Suppose an event would create an estimated $200,000 loss and is expected once every five years. The ARO is 0.2, producing an ALE of $40,000. The result can help compare treatment costs, but it remains an estimate. Uncertain assumptions should be recorded and tested rather than hidden behind precise-looking numbers.
Risk responses
| Response | Meaning | Example |
|---|---|---|
| Avoid | Stop or change the activity that creates the risk. | Do not collect information that the business does not need. |
| Mitigate | Reduce likelihood, impact, or both through controls. | Add strong authentication, segmentation, monitoring, and tested recovery. |
| Transfer or share | Shift some financial or operational consequence to another party. | Use insurance or contractual allocation while retaining accountability for unmanaged residual risk. |
| Accept | Retain the risk through an informed, authorized decision. | A risk owner approves documented residual risk within delegated authority and review conditions. |
Transfer does not remove all risk. Insurance may cover some financial losses but not safety, regulatory action, reputation, lost customers, or operational disruption. Outsourcing a service does not outsource accountability.
Control categories and functions
Controls may be described by how they are implemented:
- Administrative or managerial: policy, governance, risk assessment, training, contracts, and review.
- Technical or logical: access control, encryption, monitoring, filtering, and system-enforced restrictions.
- Physical: barriers, locks, guards, environmental systems, and facility controls.
They may also be described by function:
- Preventive
- Deterrent
- Detective
- Corrective
- Recovery
- Compensating
- Directive
One control can have several functions. A visible camera can deter activity and produce detective evidence. A backup supports recovery. A temporary manual review can compensate for an unavailable automated control.
Assessment, monitoring, reporting, and improvement
A risk process should continue after the initial decision:
- Assess whether controls are designed and operating as intended.
- Monitor changes in threats, vulnerabilities, business processes, suppliers, and technology.
- Report information at a level suited to the audience.
- Track treatment owners, deadlines, exceptions, and residual risk.
- Reassess after incidents, major changes, acquisitions, and regulatory changes.
- Measure maturity and improve the process, not only individual controls.
Executives need concise exposure, trend, decision, and accountability information. Control operators need detailed failures, thresholds, and corrective actions. Sending the same dashboard to every audience usually serves none of them well.
10. Threat modeling
Threat modeling examines how a system or process could be harmed before or during its lifecycle. It turns vague concern into structured analysis.
A useful process:
- Define the system, business purpose, assumptions, and scope.
- Identify assets, sensitive operations, users, components, data flows, and dependencies.
- Mark trust boundaries and entry points.
- Identify threat actors, capabilities, motivations, and relevant threat events.
- Examine weaknesses, misuse cases, attack paths, and failure conditions.
- Estimate risk and prioritize scenarios.
- Select design changes and controls.
- Record assumptions and unresolved risks.
- Revisit the model after design, architecture, supplier, or threat changes.
Methods such as STRIDE, attack trees, misuse cases, and process-focused approaches provide prompts. The method is a tool, not the outcome. A colorful diagram that never changes requirements or design has not reduced risk.
Threat modeling belongs early in design, but it should not stop there. New integrations, cloud services, artificial intelligence features, privilege changes, and supplier components can create new trust boundaries and attack paths.
11. Supply Chain Risk Management
Supply Chain Risk Management (SCRM) addresses risks introduced through suppliers, products, services, components, development processes, support channels, and dependencies.
Threats include:
- Counterfeit or tampered components
- Malicious implants or unauthorized functionality
- Vulnerable development and build processes
- Compromised updates or distribution channels
- Unsupported products and hidden dependencies
- Excessive supplier access
- Weak subcontractors or fourth parties
- Service concentration and geographic dependency
- Financial failure, acquisition, or loss of key personnel
- Poor incident notification and recovery capability
Supplier lifecycle controls
| Stage | Security work |
|---|---|
| Planning | Define business need, criticality, data, access, resilience, legal duties, and exit requirements. |
| Due diligence | Assess governance, controls, incidents, financial stability, development practices, dependencies, and evidence. |
| Contracting | Set minimum requirements, service levels, audit rights, notification, data handling, support, recovery, change, and termination terms. |
| Onboarding | Approve access, integrations, data flows, ownership, monitoring, and contacts. |
| Operation | Monitor performance, control evidence, incidents, vulnerabilities, changes, subcontractors, and risk indicators. |
| Offboarding | Revoke access, return or destroy data, transfer services, preserve required records, and verify completion. |
A Software Bill of Materials (SBOM) can improve visibility into software components. It does not prove that the components are secure, authentic, supported, correctly configured, or monitored. Use it as evidence within a broader supplier and vulnerability-management process.
Hardware roots of trust, physically unclonable functions, signed updates, provenance records, and controlled distribution can reduce tampering and counterfeit risk. Their value depends on implementation, verification, key management, and lifecycle support.
Artificial intelligence suppliers
Artificial intelligence services can introduce opaque data sources, model dependencies, external processing, rapidly changing features, and non-human identities. Domain 1 treats these as governance, risk, privacy, supplier, ethics, and awareness concerns rather than as a separate island.
Ask:
- Which data is collected, retained, used for training, or shared with subprocessors?
- Who owns inputs, outputs, models, and derived information?
- How are bias, unsafe output, confidentiality, integrity, and availability risks assessed?
- Which human approvals remain necessary?
- How are model changes, incidents, and service degradation reported?
- Can the organization export data and continue the process if the provider fails?
- Which employees need guidance on acceptable use, sensitive data, verification, and accountability?
12. Security awareness, education, and training
A learning program should change behavior and improve capability. Completion rates alone show that people clicked through material. They do not show that employees recognize, avoid, report, or recover from security events.
Awareness, training, and education
| Activity | Purpose | Example |
|---|---|---|
| Awareness | Keeps security concerns visible and influences everyday behavior. | Short reminders, campaign messages, posters, brief videos, and incident lessons. |
| Training | Builds the knowledge and skill needed to perform a role or task. | Secure administration, incident handling, privacy procedures, or supplier-review training. |
| Education | Develops broader understanding that supports judgment across new situations. | Formal courses, degree programs, professional study, and deeper conceptual learning. |
Program lifecycle
- Identify audiences, roles, risks, obligations, and desired behaviors.
- Define measurable learning and performance objectives.
- Select delivery methods suited to the audience and work environment.
- Provide onboarding, periodic, event-driven, and role-based content.
- Give people a simple way to ask questions and report suspicious activity.
- Measure knowledge, behavior, reporting quality, incidents, and operational outcomes.
- Improve content based on evidence, new threats, incidents, technology, and feedback.
Methods may include phishing simulations, social-engineering exercises, tabletop scenarios, security champions, coaching, games, targeted reminders, and practical exercises. Simulations should educate rather than humiliate. Metrics should discourage gaming and account for false positives, reporting speed, role differences, and repeated improvement.
Emerging topics require periodic review. Cryptocurrency, blockchain, cloud services, artificial intelligence, deepfakes, collaboration tools, and changing social-engineering methods can create new behaviors and responsibilities. Update the program when the work changes, not only when the annual training date arrives.
13. Common Domain 1 exam traps
Choosing implementation before requirements
A product, encryption method, or monitoring tool may be useful. First identify classification, business need, legal duties, architecture, risk, and ownership.
Letting the security team accept business risk
Security professionals assess and communicate risk. The authorized business or risk owner accepts residual risk.
Treating compliance as the complete security goal
Compliance can establish minimum requirements and evidence. The organization still needs to address risks outside the requirement and confirm that controls protect the business outcome.
Confusing due care with due diligence
Due care is reasonable protective action. Due diligence is the continuing effort to investigate, verify, monitor, and maintain that protection.
Assuming transfer eliminates accountability
Insurance, outsourcing, and contracts can shift some consequences. The organization retains risks that cannot be transferred and remains accountable for its obligations.
Starting an investigation without authority or scope
Confirm the purpose, authority, rules, preservation duties, privacy limits, and stakeholders before broad collection or intrusive action.
Restoring technology without restoring the business process
A server can be online while the business remains unable to operate. Account for people, data reconciliation, suppliers, facilities, identity, communications, and work recovery time.
Measuring training by completion alone
Completion is an administrative measure. Evaluate behavior, capability, reporting, incidents, and operational outcomes.
14. Domain 1 review checklist
You should be able to:
- Explain how professional ethics affects a security decision.
- Distinguish confidentiality, integrity, availability, authenticity, and nonrepudiation.
- Separate governance from management.
- Identify the authority of boards, senior management, business owners, risk owners, data owners, custodians, and assessors.
- Compare due care and due diligence.
- Explain the purpose of major governance and risk frameworks without treating them as interchangeable.
- Distinguish law, regulation, contract, industry requirement, and internal policy.
- Identify the considerations for administrative, criminal, civil, regulatory, and contractual investigations.
- Compare policies, standards, procedures, guidelines, and baselines.
- Explain how a Business Impact Analysis drives continuity and recovery priorities.
- Distinguish maximum tolerable downtime, RTO, RPO, and work recovery time.
- Apply personnel controls before access, during changes, and at termination.
- Distinguish assets, threats, vulnerabilities, likelihood, impact, inherent risk, and residual risk.
- Compare qualitative and quantitative risk analysis.
- Calculate SLE and ALE from provided values and explain their limitations.
- Compare avoidance, mitigation, transfer, and acceptance.
- Classify controls by implementation and function.
- Describe a threat-modeling process and explain why it should be repeated after significant change.
- Apply supplier controls from planning through offboarding.
- Explain what an SBOM can and cannot prove.
- Distinguish awareness, training, and education.
- Choose measures that show behavior and capability rather than attendance alone.
15. Official references
- ISC2 CISSP Certification Exam Outline
- ISC2 ethics guidance
- NIST Cybersecurity Framework 2.0
- NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
- NIST SP 800-37 Rev. 2, Risk Management Framework
- NIST SP 800-34 Rev. 1, Contingency Planning Guide
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program
- NIST Artificial Intelligence Risk Management Framework 1.0
The official ISC2 outline defines the exam objectives. The NIST publications provide detailed, publicly available context for risk assessment, lifecycle governance, continuity, supply-chain risk, learning programs, and artificial intelligence risk. CertHappens is an independent study resource and is not affiliated with or endorsed by ISC2.