Security and Risk Management

Start with the business decision

Security and Risk Management is Domain 1 of the CISSP outline. It covers professional ethics, security concepts, governance, legal and compliance issues, policies, business continuity, risk management, threat modeling, supply chain risk, and awareness programs. The domain is broader than a list of security products. Many scenarios ask you to decide who should act, what outcome matters, and how a control supports that outcome.

A useful first move is to identify the business objective. A control is not automatically good because it is technically strong. It must address a defined risk while allowing the organization to meet its mission and obligations. If a measure blocks a critical business process, the security professional should explain the tradeoff and help the accountable decision maker choose a treatment. That is different from quietly accepting the risk on the organization's behalf.

Separate the security principles

Confidentiality concerns who can see information. Integrity concerns whether information and systems remain accurate and protected from unauthorized change. Availability concerns whether authorized users can reach the services they need. Authenticity and nonrepudiation are also named in the CISSP outline: authenticity supports confidence about an identity or source, while nonrepudiation concerns evidence that supports attribution of an action or communication.

A scenario may affect several principles at once. A stolen administrator credential can threaten confidentiality through data access, integrity through unauthorized changes, and availability through destructive actions. State the affected asset and outcome before jumping to a control. That keeps the answer tied to the risk instead of to a familiar technology.

Describe risk in context

Risk analysis begins with something the organization values and a way it could be harmed. Identify the asset or process, the threat, the vulnerability or exposure, and the consequence that matters to the organization. A threat is a possible source of harm; a vulnerability is a weakness or condition that could be exploited. A risk statement connects them to a plausible business impact.

For example, a supplier's remote support account may create a path into a production environment. The relevant question is not simply whether the supplier is trustworthy. Ask what systems the account can reach, whether access is limited to a support task, how the organization knows when it is used, and what happens when the supplier relationship ends. The outline explicitly includes supplier and provider risks, third-party assessment and monitoring, minimum security requirements, and service-level requirements.

Do not confuse a vulnerability count with organizational risk. A technical finding matters when you understand its exposure, reachable assets, existing safeguards, and possible consequences. A severe weakness on an isolated test system may call for a different priority from a less severe weakness on a business-critical service exposed to an untrusted network. The facts in the scenario determine the priority.

Use threat modeling to ask focused questions

Threat modeling gives a team a structured way to consider what it is building or protecting, how information and trust move through it, what could go wrong, and which safeguards fit. The CISSP outline names threat modeling concepts and methodologies but does not prescribe one universal method. In an exam scenario, follow the method or constraints stated in the question. If none is given, reason from the system boundary, valuable assets, likely threat paths, and business impact.

For a new customer portal, map the user, application, identity service, data store, and any outside provider. Mark where credentials, personal information, or administrative actions cross a boundary. Then ask what an attacker or careless user could do at each transition. This can reveal design questions before deployment: should administrators use a separate path, should the application receive only the permissions it needs, and what evidence will show that the controls work?

Choose a risk response and assign ownership

Once the organization understands the risk, it can choose a treatment. It may reduce risk through controls, avoid an activity, transfer part of the financial impact, or retain the risk with an informed decision. Insurance may help with some financial consequences, but it does not remove the underlying threat, legal duty, or need to manage the event. The CISSP outline includes risk treatment and cybersecurity insurance, so keep the difference between risk reduction and financial transfer clear.

Risk acceptance belongs to an authorized business owner under the organization's governance process. Security staff can analyze the exposure, recommend options, and report residual risk. They should not imply that installing a control eliminates all risk, or accept an exception without the authority and documentation required by policy. If a scenario says a control is too costly or would disrupt the mission, present the tradeoffs and route the decision to the right owner.

Residual risk is what remains after planned controls are considered. A treatment is not complete merely because a project ticket says a safeguard was installed. Someone should confirm that the safeguard operates as intended, track exceptions, and monitor relevant changes. The outline includes control assessments, continuous monitoring and measurement, reporting, and continuous improvement.

Match controls to the problem

Controls can be preventive, detective, or corrective. A preventive control aims to stop an unwanted event, such as restricting a privileged account to approved tasks. A detective control helps identify activity, such as reviewing access logs. A corrective control helps contain or restore after a problem. The same control can contribute to more than one objective, but identify its intended role in the scenario.

Use least privilege, defense in depth, secure defaults, fail-secure behavior, and separation of duties as design principles when they fit. Least privilege limits permissions to what a person or process needs. Defense in depth uses multiple safeguards so a single failure does not determine the outcome. Separation of duties divides sensitive responsibilities so one person does not control every step. These are means to manage a particular risk, not answers to memorize without context.

A policy states management's direction and expectations. Standards set required rules or thresholds; procedures describe repeatable steps; guidelines offer recommended practices. The outline names these document types and asks candidates to understand their development and implementation. In a scenario, determine whether the problem is missing direction, an unclear requirement, or failure to follow an established process before proposing a new technical tool.

The same distinction helps with exceptions. If a team cannot meet a standard, the organization may have a documented exception process with an owner, rationale, compensating safeguards, and review. Do not assume an exception is an informal waiver or that approval makes the risk disappear. Ask whether the right person approved it, whether the remaining exposure is understood, and whether it will be revisited when conditions change.

Work a supplier access scenario

A company relies on a supplier to maintain a customer-facing service. The supplier requests a shared administrator password for faster support. The service owner says downtime would affect a major business process. What should the security professional do first?

Start by clarifying the business and technical context: which systems the supplier needs, which tasks require privileged access, what data or functions are reachable, how access is currently approved, and who owns the service risk. The request identifies a potential exposure, but it does not yet prove that all supplier access must stop. A response should preserve the support objective while making the risk visible.

Next, assess feasible safeguards. Individual identities make actions easier to attribute than a shared credential. Limiting access to approved systems and tasks applies least privilege. A defined approval and expiration process addresses provisioning and deprovisioning. Monitoring and review can help detect misuse. Contractual security requirements and third-party monitoring address the supplier relationship. A recovery or continuity plan addresses the service's availability need.

Then explain residual risk and obtain a decision from the service or risk owner. The security professional can recommend against an uncontrolled shared administrator password, but the risk decision needs the authorized governance path. Document the chosen controls, exceptions, monitoring, and review conditions. The exact solution depends on the environment and policy; the reasoning sequence is a study aid, not an official ISC2 formula.

Why the tempting answers fail

Immediately buying a privileged access product skips the questions about scope, ownership, and existing safeguards. Terminating the supplier may protect one path but could undermine a critical service without a continuity assessment. Accepting the shared password because the supplier is known confuses trust with control. The better response identifies the risk, proposes proportionate controls, and leaves acceptance with the authorized owner.

Connect governance, law, and continuity

Security governance ties the security function to organizational strategy, roles, policies, and oversight. A technically correct choice can still be incomplete if it ignores contractual, regulatory, privacy, licensing, intellectual property, or cross-border data obligations. The outline asks candidates to consider legal and compliance matters holistically. Do not assume one framework or law applies everywhere; use the jurisdiction and facts stated in the question.

Business continuity starts from the activities the organization must keep operating and the dependencies those activities rely on. A business impact analysis helps identify the consequences of disruption and the dependencies that matter. Recovery planning then addresses people, communications, systems, and restoration. The exam outline includes continuity requirements, external dependencies, recovery strategies, backup approaches, and several ways to test a disaster recovery plan.

Supplier outages, unavailable identity services, and lost data can all affect continuity. A backup is useful only if it can be restored in the needed situation; a recovery plan should be exercised in a way that fits its scope. The outline names read-throughs, walkthroughs, simulations, parallel tests, and full interruption tests. Choose a test that gives useful evidence without causing an unacceptable interruption.

External dependencies belong in the analysis. A business process may rely on a service provider, communications link, identity service, or specialized staff. If the organization has not identified a dependency, its recovery plan may restore the main system while leaving the process unusable. Record the dependency, the party responsible for it, and how the organization will respond if it is unavailable.

How to reason through CISSP scenarios

Read the final sentence of a scenario carefully. It may ask for the first action, the best control, the business owner's next step, or the most appropriate risk response. These are different questions. An answer can name a valid security practice and still be wrong because it occurs too late or belongs to a different role.

A practical study sequence is: name the objective; identify the asset and consequence; locate the threat or weakness; identify the responsible owner; compare treatment options; select a control that addresses the risk; and decide how its operation will be checked. This is a reasoning aid synthesized from the outline topics. It is not a scoring rule or a claim about the structure of secured exam items.

The active CISSP outline is effective April 15, 2024 and assigns 16% to Security and Risk Management. Use the official outline for the complete task list and weights. This article teaches a subset of Domain 1 through original examples; it does not cover every exam objective or reproduce an ISC2 question. Static study exercises also cannot recreate computerized adaptive testing.