ACTIVITIES

A.  Estimate overall vendor risk profile

Interview business owners, vendor managers and stakeholders and create a list of worst-case scenarios across the organization's dependence on outside parties. Based on the services and software your organization relies on, the list can vary widely, but common issues include a critical service suffering a prolonged outage, a vendor being breached and the organization's data going with it, a widely-used software component turning out to carry a serious vulnerability, and a supplier the business cannot function without going bankrupt or being acquired.

After broadly capturing worst-case scenario ideas, collate and select the most important based on collected information and knowledge about the core business. Any number can be selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep the exercise focused.

Elaborate a description of each of the selected items and document details of contributing worst-case scenarios, potential contributing factors, and potential mitigating factors for the organization.

The final vendor risk profile should be reviewed with business owners and other stakeholders for understanding.

B.  Build and maintain assurance program roadmap

Understanding the main business risks to the organization, evaluate the current performance of the organization against each of the twelve Practices. Assign a score for each Practice from 1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative success metrics. If no success metrics are being met, assign a score of 0 to the Practice.

Once a good understanding of current status is obtained, the next goal is to identify the Practices that will be improved in the next iteration. Select them based on the vendor risk profile, other business drivers, compliance requirements, budget tolerance, etc. Once Practices are selected, the goals of the iteration are to achieve the next Objective under each.

Iterations of improvement should be approximately 3-6 months, but a strategy session should take place at least every 3 months to review progress on activities, performance against success metrics and other business drivers that may require program changes.

ACTIVITIES

A.  Conduct periodic industry-wide cost comparisons

Research and gather information about vendor and supply-chain security costs from intra-industry communication forums, business analyst and consulting firms, or other external sources.

First, use collected information to identify the average effort being applied by similar organizations. This can be done top-down from estimates of total percentage of budget devoted to third-party risk, or bottom-up by identifying the assurance activities considered normal for the kinds of dependencies your organization carries.

The next goal is to determine whether there are savings available on the tooling your organization licenses for questionnaires, security ratings, software composition analysis and continuous monitoring, which is frequently bought piecemeal and overlaps. Account for hidden costs such as re-onboarding vendors when switching platforms.

These exercises should be conducted at least annually prior to the subsequent strategy session, and comparison information presented to stakeholders in order to better align the program with the business.

B.  Collect metrics for historic vendor incidents

Collect information on the cost of past vendor and supply-chain incidents. Outage and downtime losses when a service failed, breach and notification costs when a vendor lost the organization's data, emergency remediation when an inherited component proved vulnerable, and the cost of an unplanned migration when a supplier failed are the usual components.

Using the vendor tiers and the respective roadmaps for each, a baseline assurance cost per tier can be initially estimated from the costs associated with the corresponding tier.

Combine the per-tier cost information with the general cost model, then evaluate for outliers, i.e. sums disproportionate to the tier. These indicate either an error in tiering or the necessity to tune the program to address root causes more effectively.

Tracking should be done quarterly at the strategy session, and the information reviewed by stakeholders at least annually.

ACTIVITIES

A.  Identify and monitor external compliance drivers

Gather the regulations, contractual obligations and standards that place requirements on the organization's use of vendors. Many regimes now regulate third-party and supply-chain risk directly, requiring due diligence, oversight and the ability to demonstrate control over critical suppliers.

For each driver, extract the obligations that land on vendor management — due diligence before engagement, flow-down of the organization's own obligations to the vendor, breach notification from the vendor, the right to audit, and, increasingly, a bill of materials for software brought in.

Assign an owner for each driver and establish a review to catch changes, since supply-chain regulation is expanding quickly in the wake of high-profile incidents.

B.  Build and maintain vendor management guidelines

Consolidate the obligations into guidelines expressed in terms the teams who select and run vendors can act upon. Regulators speak in outcomes; procurement and engineering need to know what to require of a supplier and what evidence to collect.

Cover both threads of vendor risk. For services, this is the due diligence expected before engagement and the terms to secure. For software brought in — whether bought or open source — it is knowing what the ingredients are, tracking vulnerabilities in them, and keeping them current.

Publish the guidelines where the relevant teams work and review them at least annually.

ACTIVITIES

A.  Conduct periodic compliance audits of vendor management

Move from confirming compliance at intake to confirming it continuously. Vendor relationships drift: a service's scope expands, a supplier is acquired and its posture changes, a component falls out of maintenance, a contract lapses and is renewed on weaker terms.

Audit against the internal standards and the inventory, and look specifically for vendors in use without an assessment, critical components with no owner, and reliance that has grown beyond what was originally approved. The dependencies that entered without review are over-represented in incidents precisely because nobody governs them.

Each significant vendor should undergo audit at least biannually, with the most critical reviewed more often.

B.  Collect and control compliance evidence

Establish a repository of evidence sufficient to satisfy a regulator or auditor without a scramble: the dependency inventory, completed assessments and their supporting attestations, contract terms, vendor bills of materials, vulnerability and patch records for inherited components, and exception records.

Automate collection wherever possible, particularly the evidence that expires — attestations, certificates, penetration test summaries — which is voluminous and goes stale continuously. Evidence assembled by hand at audit time is expensive and tends not to survive scrutiny.

Report adherence to stakeholders at least quarterly, trending over time.

ACTIVITIES

A.  Conduct vendor and supply-chain risk awareness training

Offer the staff who select vendors and bring in software access to training covering the fundamentals of third-party and supply-chain risk, reflecting the kinds of dependencies your organization actually takes on.

Cover the ideas that change behavior: that responsibility for a vendor's failure usually rests with you rather than the vendor; that a service you rely on is a single point of failure and a target; that free and open-source software is still a dependency with a security posture; and that the moment to assess a vendor is before the contract is signed, when there is still leverage.

Aim to reach everyone who selects vendors or adopts components within a year, and refresh at least every two years as the threat landscape changes.

B.  Build and maintain vendor guidelines

Assemble reference guidelines covering the specific decisions your organization expects, rather than restating general advice available elsewhere.

Practical topics include how to assess a vendor before engaging it, what evidence to ask for and how to read it, what security terms to secure in a contract, how to vet an open-source component before adopting it, and what to do when a vendor announces a breach or a component announces a vulnerability.

Keep the guidelines lightweight and current. A short document that reflects today's supply-chain threats beats a comprehensive one written before they mattered.

ACTIVITIES

A.  Establish role-based examination and certification

Introduce assessment so competency is demonstrated rather than assumed, particularly for the roles that engage critical vendors or approve dependencies that will be widely relied upon.

Tie certification to authority where the risk warrants it. The ability to approve a critical vendor, or to sign off a component for organization-wide use, is a reasonable thing to gate on demonstrated understanding of the assurance involved, reviewed periodically.

For general staff, lightweight scenario-based checks — would you sign this, adopt this, escalate this — are usually more informative than a test of recall.

B.  Establish centralized guidance control

Bring the guidance under central control with clear ownership, review cycles and version history, so the organization can state with confidence what its current expectations are.

Distribute from a single authoritative source and retire superseded material actively, which matters for vendor guidance since assessment expectations and contract terms evolve as the threat landscape and regulation do.

Measure whether guidance is reaching people and being used, and feed that back into the roadmap.

ACTIVITIES

A.  Build and maintain vendor threat models

For each significant dependency, build a lightweight model of how it could harm the organization. A workshop and a page of notes per critical vendor or component is enough to start.

Work through the ways dependence turns into harm. A service goes down and takes a business process with it. A vendor is breached and the organization's data goes with it. A vendor's own supplier fails, cascading into your operation. A software component you embedded turns out to carry a vulnerability, or worse, to have been deliberately tampered with. A supplier is acquired, changes its terms, or simply goes out of business.

Record for each threat what currently stands in the way, and note explicitly where the organization has no control at all, since those are the risks that must be managed by other means.

Review the models with the teams who own each relationship and refresh at least annually.

B.  Develop actor and failure profile

Characterize how your dependencies are most likely to hurt you, spanning deliberate attack and ordinary failure. The attacker who compromises a widely-used vendor to reach its customers, the attacker who poisons an open-source package, the vendor whose own negligence exposes your data, and the supplier who simply cannot keep the service running all call for different responses.

Ground the profile in how the organization actually depends on outside parties. An organization whose critical operations run on a handful of concentrated providers carries different risk from one whose dependencies are diverse and substitutable, whatever the external threat.

Document the profiles alongside the threat models so the two are read together.

ACTIVITIES

A.  Explicitly evaluate fourth-party and concentration risk

Extend threat assessment to the dependencies behind your dependencies, and to the correlations among them, since these are where the largest surprises hide.

For fourth parties, establish what your direct vendors depend on and require them to disclose material subcontractors and to flow your requirements down to them. For concentration, identify the providers, regions and components that many of your critical dependencies share, and decide deliberately whether to reduce the concentration, arrange an alternative, or accept the correlated risk and record who accepted it.

Reassess when the landscape shifts. A merger between two of your vendors, or a widely-used component changing hands, can turn diversity into concentration overnight.

B.  Elaborate threat models with controls

Complete the mapping from each inherited threat to the specific controls that mitigate it — contractual, technical and operational — and record the residual risk that remains after those controls apply.

This mapping is what lets an organization answer the question its board actually asks after a supply-chain incident — not 'did we assess this vendor' but 'what happens to us if this vendor fails, and what stands between us and that harm'. It also exposes assurance activity that mitigates nothing in the current threat model and is a candidate for retirement.

Maintain the mapping as the estate changes, and review residual risk with business owners at least annually so acceptance is renewed deliberately.

ACTIVITIES

A.  Derive requirements from dependency criticality

For each new engagement or component, work from what it will do and what it will reach to the assurance it must provide. Start from the criticality and the access rather than a generic checklist.

A short set per dependency is enough at this level. Typical entries for a service include the security posture it must evidence, the data and access it may have, breach notification obligations, availability commitments, and an exit path. For a software component, they include a bill of materials, a maintained and responsive project, a clear licence, and a track record of fixing vulnerabilities promptly.

Have the requirements reviewed by the team that will depend on the vendor. A requirement the organization has no way to verify is not yet a requirement.

B.  Evaluate compliance and criticality for requirements

Draw on the vendor guidelines and threat models to catch requirements that criticality alone would not surface.

Compliance drivers frequently mandate specific requirements — due diligence evidence, flow-down clauses, a bill of materials — and the threat models will suggest others, particularly around concentration and continuity. Challenge the dependency itself as well: the strongest way to reduce a vendor risk is sometimes to choose a more substitutable vendor, or to not take on the dependency at all.

Consolidate into a single requirement set per engagement so the teams implementing it have one document to work from.

ACTIVITIES

A.  Build security requirements into contracts and adoption gates

Carry the organization's requirements into its contracts with vendors and into the gates through which components are adopted, since a requirement not written into the agreement is a requirement the organization cannot enforce.

The contract terms worth securing are those that are impossible to add later: breach notification obligations and timescales, the right to audit or to receive evidence, security standards the vendor must maintain, disclosure of material subcontractors, service commitments with remedies, and an exit clause covering data return and transition assistance. For components, the equivalent gate requires a bill of materials, provenance, and a clean vulnerability position before adoption.

For critical vendors, negotiate these deliberately rather than accepting the vendor's standard terms, which are written to protect the vendor.

B.  Expand audit program for vendor requirements

Extend routine audit to cover whether vendors and components in use actually meet the requirements specified for their tier, closing the loop between what was specified and what was accepted.

Audit the contract terms too. A breach notification clause is only useful if it is actually invoked when a breach occurs, and a right to audit is only useful if it is exercised. Vendors whose attestations have lapsed, or whose contracts were renewed on weaker terms, need to be brought back into line.

Report findings into the strategy session so requirement failures inform the roadmap rather than being handled solely as individual exceptions.

ACTIVITIES

A.  Maintain a list of approved vendors and component sources

Publish the vendors and the sources of outside software the organization supports, and keep it curated. A short list of vetted providers and trusted package repositories concentrates assurance effort and steers teams away from the unassessed alternative.

Base inclusion on the requirements already specified — evidenced posture, acceptable terms, a maintenance and vulnerability track record, and for software sources, integrity and provenance guarantees. Prefer providers that are substitutable and components that are actively maintained.

Record what is not approved as clearly as what is, and give the list an owner and review cadence. The unsanctioned SaaS tool and the package pulled from an untrusted source are where unassessed dependencies enter, and a clear approved list is the first defense.

B.  Identify and promote resilience and supply-chain principles

Establish the handful of principles every selection and integration decision should honor, and make them explicit so decisions can be checked against something.

The durable ones are: prefer substitutable vendors and avoid single points of failure; isolate a vendor integration so its compromise does not become yours; grant a vendor the least access its function requires; verify the provenance and integrity of software brought in; know the ingredients of everything you run; and have a way out of every critical dependency before you need one.

Circulate the principles to selection and engineering teams and use them as review criteria.

ACTIVITIES

A.  Build reference patterns for dependency onboarding

Produce complete reference patterns for the recurring ways the organization takes on dependencies — not documents describing a process, but working intake pipelines and integration templates that assess, isolate, verify and record a dependency without manual steps.

The goal is that the easy path is the safe path: a team taking on a new vendor through the reference gets the tier-appropriate assessment, the standard contract terms, an isolated integration and an inventory entry by default; a team pulling a component gets provenance and vulnerability verification automatically. This removes the largest single source of exposure, which is dependencies taken on outside any process.

Maintain the patterns under change control, and make them genuinely easier to use than the ad hoc alternative, since adoption follows convenience more reliably than policy.

B.  Validate usage of reference patterns

Verify that dependencies in service were in fact taken on through the reference patterns and remain within them, rather than assuming that publishing a pattern ensures its use.

Vendors engaged outside the standard process — on a corporate card, through a business unit's own budget, or inherited through acquisition — and components pulled from outside the curated channel are the ones that will not match, and they are where unassessed and unmonitored dependence accumulates.

Report the proportion of the estate onboarded through reference patterns as a programme metric, and route exceptions through the documented process rather than letting them accumulate silently.

ACTIVITIES

A.  Identify the exposure a proposed dependency creates

For each proposed engagement or component, document what the organization would be taking on. This is the vendor equivalent of an attack surface and it need not be elaborate.

Record what data and access the vendor would have, how it integrates, what the business would be unable to do if it failed, what the contract offers on security and exit, and — for a component — what it depends on in turn and how deeply it would be embedded. Concentration deserves explicit attention: whether this dependency piles onto a provider or component many others already rest on.

The exercise is most valuable for critical dependencies and for anything that would reach sensitive data or be hard to replace, since that is where an ill-considered commitment does lasting harm.

B.  Check the proposal against known risks and requirements

Review each proposed dependency against the organization's threat models, resilience principles and requirements, asking of each identified risk what this arrangement does about it.

Concentrate on the decisions that are hard to change later: whether the vendor can actually evidence the posture it claims, whether the contract carries notification and audit rights, whether there is a viable exit, whether a component's provenance can be verified, and whether the dependency worsens a concentration.

Record the review outcome with the proposal. Even an informal note stating who reviewed it and what was raised gives the next reviewer a starting point.

ACTIVITIES

A.  Develop detailed dependency and continuity review

Deepen review to test the necessity and resilience of each proposed dependency rather than accepting it, and to trace what happens if it fails.

Work the failure through. If this vendor went down, what stops, for how long, and what is the fallback? If it were breached, what data of ours is exposed? If it went out of business, could we get our data back and migrate, and how long would that take? For a component, what is the blast radius if a vulnerability is found in it, and how quickly could we replace it?

These questions are answerable before commitment and expensive to answer once the dependency is load-bearing.

B.  Require reviews and audit dependency compliance

Make review mandatory for critical dependencies, and verify through routine audit that the requirement is met rather than assuming it.

Audit both that reviews happened and that their conditions were implemented. A review that concluded 'approved provided a data-return clause is secured' is worth nothing if the contract was signed without one.

Feed audit findings into the strategy session so systematic review failures are addressed as programme problems rather than individually.

ACTIVITIES

A.  Create review checklists from known requirements

Build a checklist from the requirements and assurance model already defined, expressed as things that can actually be checked of a live dependency.

Keep it to what carries real weight: is the vendor on the approved list, is a current assessment and attestation on file, does the access in use match what was approved, are the contract terms in force, and for a component, is it a maintained version free of known serious vulnerabilities with its ingredients known.

Have the checklist reviewed by the teams who own each relationship, since they will know which assurances have quietly lapsed and why.

B.  Discover unassessed dependencies and review critical ones

Find the dependencies the organization actually relies on but never formally assessed, and check the critical ones against the checklist.

Manual discovery is enough to start: reconcile the vendor inventory against accounts payable, against the identity provider's list of connected applications, and against the dependency manifests of the software the organization builds. Almost every organization that looks finds critical reliance it never assessed — the SaaS trial that became load-bearing, the free API in the checkout path, the open-source library at the heart of a product.

Record findings and route them for assessment with an owner and a date. A dependency found outside the process is assessed, brought under contract, or retired — never left because it is inconvenient to address.

ACTIVITIES

A.  Customize discovery for organization-specific concerns

Extend automated discovery and analysis beyond generic checks to the dependency concerns specific to your organization that no standard tool would know.

These are usually the interesting ones: the specific component a previous incident showed to be dangerous, the vendor the organization has decided not to renew, the licence that must not enter the codebase, or the concentration threshold beyond which reliance on a single provider triggers review.

Maintain these custom rules with the same discipline as the standard checks, since a rule written after an incident years ago may now be enforcing something obsolete.

B.  Gate dependency intake against policy

Move enforcement earlier by expressing the standards as checks evaluated before a vendor is engaged or a component is pulled, so that a non-compliant dependency is prevented rather than detected after reliance has set in.

Evaluating a proposed engagement or a build change against policy turns a finding that would have taken weeks to unwind into a blocked action the author reconsiders immediately, and it produces an auditable record of what was permitted and why. Blocking a build that introduces a critically vulnerable component, or an engagement with no assessment on file, are the high-value cases.

Introduce the gate in warning mode first to understand what it would block, enforce once the noise is understood, and provide an exception route with a named approver so the gate is respected rather than circumvented.

ACTIVITIES

A.  Derive test cases from known requirements

Turn the requirements for each dependency into tests that can actually be run against the parts the organization controls, so a requirement can be shown to hold rather than asserted.

Start with the controls the organization is most relying upon. If the arrangement rests on the vendor's access being limited, the test is to confirm that a vendor credential cannot reach beyond its intended scope. If it rests on integrity of a brought-in component, the test is to verify its provenance and that tampering would be detected. If it rests on notification, the test is whether a vendor alert would actually reach the right people.

Document the expected result alongside each test so a change after a vendor update or an integration change is noticed.

B.  Test the isolation and blast radius of a vendor integration

Test what an attacker who compromised a vendor, or the vendor's own credential, could reach in your environment, since a vendor compromise reaching you is among the most common supply-chain failures.

Exercise the integration as if the vendor were hostile: attempt to move from the vendor's access to systems and data beyond its intended scope, and observe what is stopped and what is logged. The useful finding is usually not that the vendor is trustworthy but that its integration is over-privileged and unmonitored.

Test a representative integration built by the standard pattern, and record findings against the reference pattern so remediation lands in the pattern rather than on a single connection.

ACTIVITIES

A.  Employ organization-specific test cases

Generate test cases from your own dependency maps and threat models rather than a generic catalogue, so testing addresses the paths that matter for your estate.

Where a dependency map shows a concentration or a critical integration, build a test that exercises what happens when it fails or is compromised, and establishes whether the controls hold. This produces findings expressed in terms of real business impact, which is what makes them actionable outside the security team.

Include the response process in scope. Testing whether a vendor incident or an inherited vulnerability is detected, assessed and contained within the target time measures the whole system rather than any single control.

B.  Establish a reliance standard for critical dependencies

Define the testing and assurance that must be satisfied before the organization takes on critical reliance on a dependency, and hold the line on it.

Require the standard to be met through the reference onboarding pattern rather than by one-off effort, so that satisfying it is inherited by everything taken on the same way. This is the difference between assurance that scales and assurance that becomes a bottleneck.

Require audit evidence that the standard was met, and route exceptions through the documented process with a named approver.

ACTIVITIES

A.  Identify point of contact and monitor for vendor issues

Establish how the organization learns that a dependency is in trouble, and a route for acting on it, since vendor problems are frequently discovered from outside rather than announced neatly.

Vendor incidents surface through the vendor's own notification, through news and threat intelligence, through a service simply not working, and through staff noticing. Inherited vulnerabilities surface through public advisories about components the organization uses. Establish who watches for these and where a report goes, including the critical case of a customer or researcher telling you about a vendor problem before the vendor does.

Publish the route where people will find it and make sure it reaches someone who can act.

B.  Create informal vendor response capability

Assemble the people who can act when a vendor issue is reported, with the knowledge and authority to do something about it.

For a vendor incident, that means someone who can establish what the organization has exposed to that vendor, contain the connection if needed, and escalate to the vendor under the contract. For an inherited vulnerability, it means someone who can determine whether and where the organization uses the affected component and drive the patch. Many organizations discover during their first real case that nobody can quickly answer where a component is used, and that finding out consumes the time that mattered.

Write down who holds these responsibilities and how they are reached, including out of hours, since disclosures do not wait for business hours.

ACTIVITIES

A.  Conduct root-cause analysis of vendor incidents

Investigate what allowed each significant vendor incident or inherited vulnerability to harm the organization, rather than closing on the immediate remediation.

The causes worth finding are structural: the vendor was over-privileged so its compromise reached far into your environment, the exposure was unknown because the vendor was never assessed, the vulnerable component could not be located because there was no bill of materials, the outage was crippling because there was no alternative, or the concentration meant one vendor's failure took several of your services at once. Each is a programme finding — usually pointing at architecture, requirements or monitoring — rather than an incident finding.

Route causes to the Practice that owns them and track them to closure. The most common structural causes, over-privileged integrations and unknown ingredients, are addressed in Environment Hardening and Monitoring & Maintenance, and analysis is how the case for acting on them gets made.

B.  Collect and report vendor incident metrics

Instrument both processes so their performance can be measured and trended, and report results into the strategy session.

The measurements that drive behavior are time from vendor awareness to exposure assessment, time from component advisory to remediation across the estate, the proportion of incidents involving vendors that were never assessed, and the proportion of advisories the organization could answer 'are we affected' for immediately. The last is a direct measure of supply-chain readiness and usually the most sobering.

Trend over time rather than reporting snapshots, and use the data to argue for the roadmap rather than to allocate blame.

ACTIVITIES

A.  Establish an inventory of dependencies and their access

Establish and maintain a picture of what the organization depends on, what access each vendor holds, and what components its software contains, drawing on the inventory and discovery work in other Practices.

Inventory is foundational because every control is scoped by it. An organization cannot constrain a vendor it has not recorded or patch a component it does not know it runs, and the dependencies missing from inventory are disproportionately those taken on outside the standard process, which are also disproportionately over-privileged and unpatched.

Reconcile sources rather than trusting one. Accounts payable, the identity provider, the software bill of materials and what business units report will each know about dependencies the others do not, and the differences are the finding.

Record an owner for every significant dependency, since ownerless vendors are neither monitored nor offboarded and ownerless components are neither patched nor retired.

B.  Apply baseline constraints to vendor access and components

Establish baseline controls: limit what each vendor can reach, and keep inherited components at supported versions.

Grant each vendor the least access its function requires and no standing access it does not actively need, and isolate the integration so that a compromise of the vendor is not automatically a compromise of your environment. Remove access for vendors no longer in use, which reconciliation reliably shows to be a longer list than expected.

For inherited software, keep components on maintained, supported versions and off end-of-life ones. Handle the highest-tier dependencies first and measure coverage, since the meaningful number is how much of the critical estate is actually constrained and current in practice, which is usually less than policy assumes.

ACTIVITIES

A.  Enforce provenance and integrity across the supply chain

Extend control so that what enters the organization from outside is verified rather than trusted, since the most damaging supply-chain attacks deliver tampered but superficially legitimate software.

Verify the provenance and integrity of components and vendor-supplied software before it is used — signed artifacts, checked build provenance, and a curated channel through which everything must pass — so that a tampered or typosquatted package cannot enter unnoticed. For critical vendors, extend assurance to their own supply-chain controls, since your integrity depends on theirs.

Verify these protections hold where software actually enters, including the paths that bypass the main pipeline — a developer's machine, an emergency patch, a vendor's direct update channel.

B.  Reduce unaccounted dependence and expand the hardening audit

Attack the root cause by depending on less that is unassessed, and bring the controls under routine audit so their continued effectiveness is verified rather than assumed.

Drive down unaccounted dependence: retire vendors no longer used, consolidate redundant ones, remove unused components from what the organization builds, and reduce the concentrations that turn one failure into many. Every dependency not carried is one that cannot fail, be breached, or harbor a vulnerability.

Audit should confirm both that controls are present and that they are effective — a vendor integration nominally brokered but with a standing back-door credential, or composition analysis that runs but whose findings nobody actions, is present but protecting little. Report into the strategy session so systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Capture vendor posture and vulnerability telemetry

Identify the information required to establish the current state of the organization's dependencies and ensure it is collected and retained centrally.

The core set is the status of each vendor's assessment and attestations, the activity of vendor integrations, an up-to-date bill of materials for inherited software, and a feed of advisories affecting the components in use. The bill of materials deserves emphasis, since without it the organization cannot answer the single most important question of a supply-chain incident — whether it is affected — and every other capability in this Practice depends on having it.

Collect vendor integration activity to a destination the vendor cannot reach, so a compromised vendor cannot erase the record of what it did.

Review the collected set with the people who respond to vendor incidents, since they will know which signal they most often wish they had.

B.  Document procedures for typical vendor alerts

For the alerts vendor monitoring routinely produces, document what they mean and what the recipient should do.

Cover the common ones: a vendor breach announced, a critical vulnerability disclosed in a component in use, a vendor's security rating dropping, an attestation expiring, unusual activity on a vendor integration, and a vendor service degrading. For each, record the likely benign explanation as well as the serious one, since most have both — the rating drop is sometimes a scanning artifact.

Keep the procedures where responders work, and review them when the estate or the advisory volume changes materially.

ACTIVITIES

A.  Expand audit program for vendor monitoring

Bring the monitoring itself under audit, verifying that the signal the organization believes it has on its dependencies is actually arriving and being watched.

Audit for gaps rather than volume. The questions that matter are which critical vendors are not being monitored, which inherited components are outside the advisory feed, which attestations have lapsed unnoticed, and which alerts were raised and never actioned. A component outside the feed generates no advisories, which is easily mistaken for an absence of vulnerabilities.

Verify the bill of materials is current and complete, since it is the foundation the whole Practice rests on and it goes stale with every build that is not re-scanned.

B.  Validate vendor offboarding and access removal

Establish and verify that vendor relationships are ended cleanly, so that a vendor no longer used retains no access to, and holds no data of, the organization.

The sequence needs to be explicit and confirmed: revoke the vendor's credentials and remove its integrations, confirm the return or destruction of the organization's data to the standard the contract requires, retrieve anything the organization needs to continue without the vendor, close the commercial relationship, and remove the vendor from inventory with a recorded disposition.

Audit the outcome by reconciliation: check terminated vendors against those still holding active credentials, still integrated, or still holding data under an expired agreement. This reliably finds relationships ended on paper but not in practice — the dormant integration, the standing API key, the data a former vendor never confirmed it deleted — which are a favored and long-lived route in.