Security and Risk Management

Decision frame

Security exists to support organizational objectives within acceptable risk and binding obligations. Senior security professionals advise, design, monitor, and escalate; accountable business leaders own business risk. When an exam scenario offers a tempting technical fix, first identify authority, safety, legal or contractual duties, affected assets, business impact, and the decision owner.

Use this sequence: understand context → identify obligations and assets → assess risk → select treatment and controls → obtain authorization → implement → measure → improve.

Objective map

Ethics, principles, and governance

Apply the ISC2 Code of Ethics and organizational ethics when duties conflict. Protect society and the common good, act honorably and legally, provide diligent service, and advance the profession. In a scenario involving concealment, unsafe action, or pressure to ignore a duty, escalate through authorized channels and preserve facts. Do not exceed authority in the name of security.

Translate security principles into business consequences. Confidentiality limits unauthorized disclosure. Integrity protects correctness and authorized change. Availability ensures timely, reliable access. Authenticity supports confidence in identity or origin. Nonrepudiation provides evidence that can resist a party's denial under the relevant process. Controls may support several properties, but state the primary requirement before choosing one.

Governance establishes direction and accountability. The board and executives set risk appetite and oversight. Management assigns owners and resources. Data and system owners make classification and access decisions. Custodians operate controls. Security advises, monitors, and reports. Internal audit provides independent assurance. Clear separation matters: the person implementing a control should not be the only person deciding whether it is effective.

Due care is the conduct reasonably expected to protect interests; due diligence is the ongoing investigation, verification, and monitoring used to sustain that care. Policies and evidence help demonstrate both, but the exact legal meaning depends on jurisdiction and facts.

Obligations, investigations, and policy

Identify applicable law, regulation, contract, industry rule, privacy duty, intellectual-property requirement, and data-transfer restriction before designing controls. Requirements can conflict across jurisdictions. Security professionals should identify and escalate the conflict to qualified legal and business authority, not improvise legal advice.

Investigation type changes authority and evidence procedure. Criminal, civil, regulatory, administrative, internal, insurance, and incident investigations can have different standards, privacy limits, discovery obligations, and reporting paths. Preserve evidence integrity, document collection and transfer, use approved tools, and involve legal or human-resources teams when required. Technical access does not automatically create investigative authority.

Policy expresses management intent and mandatory direction. Standards define required controls or measures. Procedures define repeatable steps. Guidelines provide recommended discretion. Baselines establish an approved minimum configuration. Keep documents approved, communicated, versioned, exception-aware, reviewed, and connected to enforcement and evidence.

Business continuity and personnel

Business continuity begins with business impact analysis, not technology inventory. Identify critical products and processes, people, facilities, data, suppliers, applications, dependencies, maximum tolerable disruption, recovery time, and recovery point. Management approves priorities because simultaneous recovery of everything is unrealistic. Security and resilience teams design strategies that meet those priorities and exercise them.

Personnel security spans role definition, screening proportional to risk and law, agreements, awareness, onboarding, access provisioning, transfers, leave, performance issues, termination, contractors, and third parties. Trigger access change from authoritative lifecycle events. Remove or adjust access promptly, recover assets, preserve records, and separate hostile-termination handling from routine offboarding.

Risk management

Define scope and assets, identify threats and vulnerabilities, analyze likelihood and impact, compare to appetite and tolerance, select treatment, assign ownership, implement controls, and monitor residual risk. Qualitative methods support relative decisions; quantitative methods estimate financial values but depend on uncertain inputs. Single loss expectancy, annualized rate of occurrence, and annualized loss expectancy can structure estimates, but false precision is dangerous.

Treatment choices are avoid, mitigate, transfer/share, or accept. Insurance can transfer some financial impact but rarely transfers accountability, legal duty, reputation, or operational disruption. Risk acceptance requires an authorized owner, defined residual risk, rationale, duration, monitoring, and review. Security cannot accept business risk simply because it found the issue.

Controls may be administrative, technical, or physical and may deter, prevent, detect, correct, recover, or compensate. Select from threat, asset value, requirement, feasibility, assurance, lifecycle, cost, and human impact. Defense in depth should create independent barriers and evidence, not duplicate the same failure mode.

Threat models, suppliers, and education

Threat modeling identifies assets, trust boundaries, actors, entry points, threats, abuse paths, and assumptions. Prioritize credible paths, map controls to them, and define validation. Keep the model current as architecture and suppliers change. A list of threats without ownership and tests is incomplete.

Supply-chain risk covers vendors, cloud services, software, hardware, components, data, personnel, concentration, provenance, tampering, support, and exit. Perform due diligence before selection; establish security, incident, audit, notification, vulnerability, data, subcontractor, continuity, return/destruction, and termination requirements in contracts. Monitor performance and changes. A certification report is useful evidence, not a guarantee for the customer's use case.

Awareness builds broad recognition and expected behavior. Training develops job skills. Education builds deeper understanding and judgment. Tailor by role and risk, use current scenarios, reinforce behavior, and measure reporting, secure practice, simulation outcomes, incidents, and control use rather than completion alone.

Decision patterns

Scenario drill

A supplier supporting a critical service reports a breach but cannot yet confirm customer-data impact. Operations wants silence until facts are complete; legal duties and contract notification periods may apply.

1. Activate the approved supplier and incident processes and preserve communications and evidence.
2. Identify data, services, dependencies, jurisdictions, contracts, notification duties, and decision authority.
3. Separate confirmed facts, assumptions, and unknowns; assess business and continuity risk.
4. Apply proportionate containment or compensating controls without exceeding authority.
5. Let qualified legal and executive owners decide notifications under the applicable timeline.
6. Track corrective actions, supplier assurance, residual risk, and retest.

Common traps

• Letting the security team accept risk owned by the business.
• Treating compliance as the complete security objective.
• Assuming technical access grants investigative authority.
• Restoring systems before personnel safety and business priorities.
• Using quantitative risk numbers as precise predictions.
• Transferring insurance cost and claiming the underlying risk disappeared.
• Measuring education only by course completion.

Self-check

1. Distinguish risk owner, system owner, data owner, custodian, security, and audit.
2. Map one requirement into policy, standard, procedure, evidence, and exception.
3. Choose and justify a risk treatment for one supplier scenario.
4. Build a threat model from trust boundary to validation test.
5. Define a behavioral measure for a role-specific security program.

Primary references

• ISC2 CISSP exam outline
• NIST Cybersecurity Framework 2.0
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management