Portfolio practice / 3 MIN READ
A shared-supplier dependency map for a GRC portfolio
Use a fictional three-service map to distinguish direct vendors, shared dependencies, missing evidence and a supported follow-up.
On this page
Two contracts with different suppliers do not establish two independent ways to keep a business activity running. They may rely on the same underlying service. A small dependency map helps you identify that question without pretending that a diagram proves resilience.
This is original fictional portfolio practice. NIST CSF2.0 includes outcomes for knowing and prioritizing suppliers and assessing supply-chain risks. The exercise illustrates a reasoning task; it is not a prescribed NIST template or evidence of conformance.
Start with the business function
Fictional Linden uses three contracted services. Its assessment packet contains the following dated disclosures:
| Direct service | Business function | Supplied dependency evidence |
|---|---|---|
| Atlas Forms | Receives new customer requests | Disclosure says authentication requires Harbor Identity |
| Birch Desk | Lets staff process those requests | Disclosure also names Harbor Identity for authentication |
| Cedar Archive | Stores an exported request record | No current dependency disclosure supplied |
Keep the link type explicit: Atlas and Birch depend on Harbor for authentication, not necessarily for every part of their service. Keep the date and source beside each link. Cedar's blank is unknown; it is not evidence that Cedar has no underlying dependencies.
Write a bounded disruption scenario
If Harbor authentication is unavailable and both disclosures apply to the deployed configurations, access to Atlas and Birch may be affected together. That is a shared dependency worth investigating. It is not yet a measured outage probability, a proof that data is lost or a conclusion that the suppliers are unacceptable.
The next questions concern the actual configuration, existing-session behavior, alternative access arrangements and the business activity's tolerance for interruption. The same provider name does not establish that both services use the same region or failover design. Do not invent those links.
Separate the map from the decision
| Proposed statement | What the current packet supports |
|---|---|
| We use three vendors, so one outage cannot affect all work | Unsupported; supplier count does not establish independence |
| Two services disclose a common authentication dependency | Supported, within the dated disclosures' scope |
| Cedar is an independent fallback | Unknown; dependency and usability evidence is missing |
| We should replace every service using Harbor | A decision requiring impact, alternatives and authorized judgment |
An appropriate follow-up might request confirmation of the two disclosed configurations and the missing Cedar dependency information. Then ask the responsible owner to evaluate a scenario affecting the request-to-processing workflow. In a real organization, use authorized channels and applicable requirements; this exercise does not authorize contacting suppliers.
Revise one link when new evidence arrives
A later technical record shows Birch uses a separate authentication option in Linden's deployment. Retain the original disclosure, add the configuration evidence and revise the Birch-to-Harbor link with its reason. Do not erase the earlier uncertainty or conclude that Birch has no other dependencies.
Label your portfolio file fictional and include the map, source register, scenario and revised conclusion. Use supplier-dependency preparation resources to compare free map practice with a connected fictional supplier packet. Use the vendor-risk interview case when the service's basic use and access are still unclear.
PUT IT INTO PRACTICE
Risk & Evidence Portfolio Kit
Connect the individual document to a complete fictional case, with registers and a versioned decision memo.