CISSP Domain: Domain 1 – Security and Risk Management

CISSP Objective: 1.9 Understand and apply risk management concepts

Focus:Third-Party Risk Management (TPRM), Supply Chain Risk Management (SCRM), Vendor Risk & External Dependencies

Organizations rarely operate within their own security boundaries. Cloud providers, software vendors, contractors, consultants, managed service providers, business partners, suppliers, and fourth parties can all introduce risk.

For the CISSP exam, the central principle is:

Third-Party Risk Management (TPRM) focuses on risks arising from external organizations and service providers. Supply Chain Risk Management (SCRM) takes a broader view, addressing risks throughout the interconnected ecosystem that produces, delivers, operates, and supports products and services.

The CISSP candidate should understand these concepts primarily from a governance, business, risk, contractual, and lifecycle perspective.

Why Third-Party and Supply Chain Risk Matter

An organization can have excellent internal controls and still suffer a serious security incident because of a supplier.

Consider an organization that uses:

• SaaS applications

• Cloud infrastructure

• Managed security services

• Software libraries

• Contractors

• Payment processors

• Data analytics providers

• Hardware manufacturers

• Outsourced development

• Business partners

Each dependency expands the organization's effective attack surface.

A compromised supplier may expose confidential information, introduce malicious software, interrupt critical services, violate regulatory obligations, or provide attackers with trusted access to the organization.

Therefore:

Your security posture increasingly depends on the security posture of organizations you do not directly control.

1. Third-Party Risk Management

Third-Party Risk Management (TPRM) is the structured process used to identify, assess, manage, monitor, and terminate risks associated with external organizations.

Third parties can include:

• Vendors

• Suppliers

• Contractors

• Consultants

• Cloud providers

• Managed service providers

• Outsourcing companies

• Software vendors

• Data processors

• Business partners

TPRM should not begin after the contract has been signed.

Security and risk considerations should be incorporated throughout the relationship lifecycle.

CISSP Exam Principle

Assess risk before establishing the relationship whenever possible.

Discovering unacceptable security risk after a critical vendor has already become operational greatly reduces the organization's options.

2. What Is Supply Chain Risk Management?

Supply Chain Risk Management considers risks arising throughout the chain of organizations, technologies, components, services, people, and processes required to deliver a product or service.

A simplified technology supply chain might look like:

Organization → SaaS Provider → Cloud Provider → Software Vendor → Open-Source Components

The organization's direct vendor may therefore depend on organizations with which the customer has no direct contractual relationship.

This creates concentration, dependency, visibility, and fourth-party risk.

SCRM asks questions such as:

• Where do critical products and services originate?

• Who has access to sensitive systems or information?

• What components are embedded within products?

• What subcontractors does the supplier use?

• How are software updates produced and distributed?

• How are components verified?

• What happens if a supplier becomes unavailable?

• How quickly can the organization replace a critical supplier?

SCRM is therefore broader than simply conducting a vendor security questionnaire.

3. TPRM vs. SCRM

The concepts overlap but should not be treated as identical.

A useful CISSP distinction is:

TPRM asks whether a vendor creates unacceptable risk.

SCRM asks how risk can propagate through the entire supply ecosystem.

4. The Third-Party Risk Management Lifecycle

Third-party security should be treated as a lifecycle.

Step 1 — Identify the Business Need

Before selecting a supplier, determine:

• What service is required?

• What business process will depend on it?

• What information will the supplier access?

• How critical is the service?

• What regulatory requirements apply?

Risk decisions should begin with the business requirement, not with a vendor's product features.

Step 2 — Classify the Vendor

Not every supplier requires the same level of scrutiny.

A company delivering office furniture does not normally create the same cyber risk as a cloud provider processing confidential customer information.

Vendor classification may consider:

• Data sensitivity

• Privileged access

• Network connectivity

• Business criticality

• Regulatory exposure

• Transaction volume

• Geographic location

• Operational dependency

• Recoverability

• Subcontractor dependence

This supports risk-based due diligence.

Higher-risk suppliers receive greater scrutiny.

5. Vendor Due Diligence

Due diligence means investigating and evaluating the supplier before making or continuing a risk decision.

The organization may evaluate:

• Security governance

• Security policies

• Access controls

• Encryption

• Vulnerability management

• Incident response

• Business continuity

• Disaster recovery

• Privacy practices

• Personnel security

• Regulatory compliance

• Data handling

• Subcontractor management

• Secure development

• Financial stability

Evidence may include:

• Questionnaires

• Interviews

• Certifications

• Audit reports

• Independent assessments

• Penetration-test summaries

• Security documentation

• Business continuity documentation

The depth of the assessment should correspond to the risk.

CISSP Thinking

The BEST answer is rarely:

A stronger approach is:

6. Due Care and Third Parties

Due diligence and due care are closely related but different.

Due diligence involves investigation and analysis.

Due care involves taking reasonable action based upon what was discovered.

For example:

The organization evaluates a cloud provider and discovers inadequate encryption controls.

That investigation represents due diligence.

Requiring remediation, selecting another provider, or formally addressing the risk demonstrates due care.

An organization that identifies serious supplier risk but ignores it may have performed due diligence without exercising adequate due care.

7. Vendor Risk Assessment

After identifying relevant threats and vulnerabilities, the organization evaluates the resulting risk.

A basic relationship is:

Risk = Threat × Vulnerability × Impact

The exact methodology varies, but CISSP candidates should understand the reasoning.

Suppose a vendor:

• Processes highly sensitive information

• Has privileged connectivity

• Provides a business-critical service

• Has weak security controls

The potential impact is much greater than that of a low-criticality supplier without system or data access.

The organization may then:

• Avoid the risk

• Mitigate the risk

• Transfer some consequences of the risk

• Accept the residual risk

Risk acceptance should occur at the appropriate management level, based on organizational policy and authority.

8. Contracts as Security Controls

A contract is not merely a purchasing document.

It can be an important administrative and legal control for third-party security.

Contracts should clearly establish applicable requirements, responsibilities, rights, and expectations.

Depending on the relationship, provisions may address:

• Information security requirements

• Data ownership

• Data handling

• Privacy requirements

• Encryption

• Access control

• Incident notification

• Breach responsibilities

• Audit rights

• Regulatory compliance

• Subcontractors

• Business continuity

• Disaster recovery

• Data return

• Data destruction

• Termination

• Insurance

• Liability

• Service availability

CISSP Exam Principle

Security requirements should be established before the contract is finalized, not added only after a problem occurs.

9. SLA, SLR and Security Requirements

These terms can appear similar on the exam.

Service-Level Requirement (SLR)

An SLR identifies what the customer requires from the service.

For example:

Service-Level Agreement (SLA)

An SLA formally establishes agreed service-performance expectations.

It may include:

• Availability

• Response times

• Resolution times

• Recovery requirements

• Support requirements

• Performance metrics

• Escalation procedures

Security-related expectations can also be incorporated into agreements.

Remember:

10. Right-to-Audit Clauses

Organizations should obtain sufficient assurance that suppliers continue to meet contractual and security requirements.

A right-to-audit clause establishes contractual authority to evaluate relevant aspects of the supplier's controls.

Depending on the relationship, assurance may come from:

• Direct audits

• Independent audits

• Third-party assurance reports

• Certifications

• Assessments

• Evidence reviews

A CISSP candidate should recognize an important limitation:

Management must determine whether the evidence is adequate for the organization's particular risk.

11. SOC Reports and Third-Party Assurance

Independent assurance reports can help organizations evaluate service providers.

CISSP candidates should understand the general distinction:

SOC 1

Primarily concerned with controls relevant to financial reporting.

SOC 2

Addresses controls associated with the Trust Services Criteria, including areas such as:

• Security

• Availability

• Processing integrity

• Confidentiality

• Privacy

Type I vs. Type II

A simplified exam distinction:

Type I: evaluates control design at a point in time.

Type II: evaluates design and operating effectiveness over a period of time.

For ongoing vendor assurance, Type II evidence can therefore provide additional insight into whether controls have actually operated over time.

12. Fourth-Party Risk

Your vendor may depend on another vendor.

That organization becomes part of your extended risk ecosystem.

For example:

Your Organization → Payroll SaaS Provider → Cloud Provider

You may have a contract with the payroll company but no direct relationship with its cloud provider.

Yet failure at the cloud provider could affect your organization.

This is fourth-party risk.

Organizations should therefore understand:

• Critical subcontractors

• Hosting dependencies

• Data-processing chains

• Concentration risk

• Geographic dependencies

• Critical technology dependencies

The principle is:

13. Concentration Risk

Concentration occurs when multiple important business functions depend upon the same provider, technology, region, or supply-chain component.

For example:

Ten critical applications may appear independent but all operate through the same cloud region.

The organization therefore has a hidden common dependency.

Concentration risk can arise from:

• Single cloud providers

• Geographic regions

• Identity providers

• DNS services

• Network providers

• Software libraries

• Hardware suppliers

• Managed service providers

CISSP candidates should think beyond individual system availability and identify common points of dependency and failure.

14. Software Supply Chain Risk

Modern software rarely consists entirely of code written by one organization.

Applications can incorporate:

• Open-source libraries

• Commercial libraries

• APIs

• Containers

• Development tools

• Build systems

• Package repositories

• Cloud services

• Third-party code

An attacker may therefore compromise the development or distribution process rather than attack the final customer directly.

Important software supply-chain considerations include:

• Component provenance

• Dependency management

• Code integrity

• Secure repositories

• Build pipeline security

• Code signing

• Patch management

• Vulnerability monitoring

• Software composition analysis

• Controlled access to development systems

15. Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) provides an inventory of components contained within software.

Think of it as an ingredient list for software.

An SBOM can help organizations determine:

• Which components are present

• Which versions are being used

• Whether vulnerable components exist

• Which applications may be affected by a newly discovered vulnerability

• Where supply-chain dependencies exist

An SBOM improves visibility.

However:

It helps organizations understand what is present so that risk can be evaluated and managed.

16. Hardware Supply Chain Risk

Supply-chain security is not limited to software.

Hardware risks can include:

• Counterfeit components

• Unauthorized modifications

• Malicious firmware

• Component substitution

• Tampering

• Untrusted manufacturing

• Poor chain of custody

• Compromised distribution

Organizations may mitigate these risks through:

• Approved suppliers

• Procurement controls

• Component verification

• Tamper evidence

• Chain-of-custody controls

• Provenance verification

• Testing and inspection

Again, the CISSP perspective is risk management rather than detailed electronics engineering.

17. Cloud and Outsourcing Risk

Moving a service to the cloud changes how responsibilities are distributed.

It does not eliminate the organization's responsibility to manage risk.

The organization should understand:

• Shared responsibility

• Data ownership

• Data location

• Access responsibilities

• Security responsibilities

• Logging

• Incident handling

• Availability

• Backup

• Recovery

• Exit procedures

One of the most important CISSP principles is:

18. Data Ownership and Data Custody

Third-party relationships make this distinction particularly important.

The data owner is generally responsible for determining appropriate classification and protection requirements.

A custodian implements and operates controls according to those requirements.

A cloud provider may therefore act as a custodian of information without becoming its business owner.

Outsourcing storage does not automatically transfer ownership or accountability.

19. Data Location and Transborder Data Flow

Third parties may store or process information in different countries.

This can introduce:

• Privacy requirements

• Data sovereignty concerns

• Contractual restrictions

• Regulatory requirements

• Jurisdictional issues

Organizations should understand where sensitive information is stored, processed, backed up, and transmitted.

This becomes particularly important with cloud and multinational suppliers.

20. Vendor Access and Least Privilege

Third-party personnel should receive only the access required to perform authorized responsibilities.

Controls can include:

• Least privilege

• Role-based access

• MFA

• Privileged access management

• Time-limited access

• Logging

• Monitoring

• Periodic access reviews

• Immediate revocation when no longer required

Vendor accounts should not become forgotten permanent access paths into the organization.

21. Continuous Vendor Monitoring

A vendor that was secure when selected may not remain secure.

Organizations change.

They can experience:

• Acquisitions

• Financial problems

• Security incidents

• Leadership changes

• Infrastructure changes

• New subcontractors

• Regulatory problems

• Control failures

Therefore, TPRM should include ongoing monitoring.

Monitoring may include:

• Periodic reassessments

• Audit-report reviews

• Certification reviews

• Performance monitoring

• SLA monitoring

• Incident monitoring

• Vulnerability information

• Compliance reviews

• Risk reassessment

The frequency and depth should reflect vendor criticality and risk.

22. Vendor Incident Management

Contracts and procedures should establish how security incidents involving third parties are handled.

Important questions include:

• Who must notify whom?

• How quickly must notification occur?

• Who leads investigation?

• What evidence must be preserved?

• Who communicates with regulators?

• What cooperation is required?

• How will affected systems be contained?

• What remediation is required?

Organizations should not attempt to design these processes for the first time during an active breach.

23. Business Continuity and Supplier Resilience

A vendor may have excellent confidentiality controls and still represent unacceptable risk if it cannot maintain critical services.

Third-party assessments should therefore consider:

• Business continuity

• Disaster recovery

• Redundancy

• Recovery capability

• Backup

• Geographic concentration

• Financial viability

• Alternate suppliers

Security includes availability.

A critical supplier failure can become your business continuity incident.

24. Exit Strategy and Vendor Offboarding

A frequently overlooked component of TPRM is the end of the relationship.

Organizations should plan for termination before they need it.

An exit strategy may address:

• Data return

• Secure data destruction

• Account termination

• Credential revocation

• Equipment return

• Key revocation

• Integration removal

• Knowledge transfer

• Records retention

• Transition to another supplier

• Confirmation of destruction

This is particularly important when a supplier possesses sensitive information or privileged access.

CISSP Exam Principle

25. Vendor Lock-In

Vendor lock-in occurs when moving to another supplier becomes difficult or expensive.

Causes may include:

• Proprietary technologies

• Proprietary data formats

• High migration costs

• Complex integrations

• Contractual restrictions

• Specialized expertise

• Large data volumes

Vendor lock-in can affect:

• Availability

• Resilience

• Negotiating power

• Exit strategy

• Business continuity

This is why exit planning should occur during procurement and contract development—not merely when termination becomes necessary.

26. Risk Transfer Does Not Mean Risk Disappears

Organizations sometimes use:

• Contracts

• Indemnification

• Insurance

• Outsourcing

to transfer some financial or operational consequences of risk.

However, risk transfer does not necessarily transfer all consequences.

A cloud provider may financially compensate an organization after an outage, but the organization may still experience:

• Reputation damage

• Customer loss

• Regulatory consequences

• Operational disruption

Therefore:

27. Third-Party Risk Register

Significant supplier risks should be incorporated into the organization's risk-management process.

A risk register may document:

• Supplier

• Business owner

• Service

• Criticality

• Assets/data affected

• Threat

• Vulnerability

• Likelihood

• Impact

• Existing controls

• Residual risk

• Risk owner

• Treatment

• Review date

Third-party risk should not operate as an isolated procurement exercise.

It should feed the organization's overall risk-management program.

28. AI Supply Chain Risk

AI introduces another important layer of supply-chain dependency.

Organizations may depend on:

• Foundation models

• AI APIs

• Training datasets

• Model repositories

• Cloud AI services

• Third-party AI applications

• AI development frameworks

• Plugins and integrations

Questions CISSP candidates should conceptually recognize include:

• Where did the model or data originate?

• Who controls the service?

• What information is being sent to the provider?

• Can sensitive information be retained?

• What third parties support the AI service?

• How are models and components updated?

• How are AI-related risks monitored?

The underlying CISSP principle remains unchanged:

New technology does not remove the need for governance, due diligence, accountability, risk assessment, and continuous monitoring.

CISSP Exam Thinking: Third-Party & SCRM Questions

Third-party questions frequently test decision sequence.

If the question asks what should happen FIRST, look for an answer involving:

Understand the business requirement → identify/classify the risk → assess the vendor → establish requirements → contract → monitor.

Do not immediately jump to a technical control.

Example

A business unit wants to immediately begin using a new SaaS provider that will process confidential customer information. What should the security manager do FIRST?

A. Require multifactor authentication

B. Conduct a vendor risk assessment

C. Install additional monitoring software

D. Purchase cyber insurance

Best answer: B — Conduct a vendor risk assessment.

The organization must first understand the risk associated with the provider and service. Appropriate controls and contractual requirements can then be determined.

Common CISSP Traps

Trap 1: "The vendor is certified, so the risk is acceptable."

Incorrect.

Certification is evidence that supports assessment. Management must still evaluate the risk in the organization's context.

Trap 2: "Outsourcing transfers accountability."

Incorrect.

Operational responsibility may be delegated, but management retains accountability for organizational risk.

Trap 3: "The SLA is enough."

Incorrect.

An SLA primarily addresses agreed service expectations. Security, privacy, audit, incident, data, termination and other obligations may require broader contractual provisions.

Trap 4: "Assess the vendor once."

Incorrect.

Material third-party relationships require ongoing monitoring proportionate to risk.

Trap 5: "Start with the technical control."

Usually incorrect when the question is governance-oriented.

CISSP generally expects:

Business requirement → Risk assessment → Management decision → Control implementation.

Trap 6: "Every vendor receives identical scrutiny."

Incorrect.

Third-party management should be risk-based.

High-Yield CISSP Memory Map

Remember the third-party lifecycle:

IDENTIFY → CLASSIFY → ASSESS → CONTRACT → MONITOR → OFFBOARD

And the broader supply-chain perspective:

KNOW THE SUPPLIER → KNOW THE DEPENDENCIES → KNOW THE COMPONENTS → KNOW THE RISK → VERIFY CONTROLS → MONITOR CHANGE → PLAN THE EXIT

Key CISSP Takeaways

For the exam, remember these principles:

1. Third-party risk remains organizational risk.

2. Assess critical vendors before establishing the relationship.

3. Apply due diligence proportionate to risk.

4. Security requirements belong in contracts.

5. Independent reports provide assurance—not guarantees.

6. Understand fourth-party and concentration risk.

7. Monitor critical suppliers throughout the relationship.

8. Protect software and hardware supply chains.

9. SBOMs improve component visibility but do not prove security.

10. Plan vendor termination and data disposition in advance.

11. Outsourcing responsibility does not eliminate management accountability.

12. Third-party risk belongs within enterprise risk management.

Related Topics

Final Exam Perspective

Third-party and supply-chain questions are ultimately questions about governance and accountability.

The CISSP is expected to think beyond whether a vendor has encryption, MFA, certifications, or a good security questionnaire. The larger question is whether the organization has identified the business dependency, evaluated the risk, established appropriate contractual requirements, verified controls, monitored the relationship, understood downstream dependencies, and prepared for failure or termination.

When two CISSP answers both appear reasonable, favor the answer that demonstrates:

risk assessment before control selection, business requirements before technology, appropriate management accountability, lifecycle risk management, and protection of the organization's mission.

That is the CISSP mindset for third-party and supply-chain risk.