What GV.OC-05 dependencies on external resources requires
An assessor or customer who asks how the organization knows what it relies on outside its walls is asking for GV.OC-05. The Subcategory expects the organization to understand the external resources its outcomes, capabilities and services depend on, and to be able to show that understanding. In practice, that means a current record of the facilities, cloud hosting providers and other outside resources that the business needs, along with a clear view of which of them could stop a critical service if they failed. NIST's Implementation Examples describe two steps: inventorying these dependencies and how they relate to assets and business functions, and documenting the ones that could be points of failure for critical services.
GV.OC-04 looks outward, asking which services customers and other external stakeholders rely on the organization to deliver. GV.OC-05 looks inward, asking what the organization itself depends on to deliver them. The two are linked: a dependency that matters to a critical service is usually visible only after the business impact of that service is understood. The lineage is also worth knowing. According to NIST's CSF 1.1 to 2.0 Core transition spreadsheet, GV.OC-05 absorbs part or all of CSF 1.1 ID.BE-1 and ID.BE-4, so teams that already tracked business dependencies under the older Identify function have a starting point, though the outcome is now framed under Govern.
The difficulty is that dependency knowledge is rarely held in one place. Contracts and renewal dates sit with procurement, cloud accounts and SaaS subscriptions sit with IT, and colocation, power and site arrangements sit with facilities, and each team records only its part. A useful first step is to ask each function for its list of outside providers and to reconcile those lists against the asset inventory and the critical services already identified. Confirm with your own teams which records exist, who keeps them current, and whether they name the business function each dependency supports. Those gaps, rather than the framework text, are usually what an assessor finds first.
Which dependencies fall in scope for GV.OC-05
GV.OC-05 asks the organization to know what its own services rely on and where a single external failure would stop critical work. The cards below cover the dependency types that usually belong in that inventory, plus the scoping choices that change how much work the inventory becomes.
Facilities and colocation sites
Data centers, colocation cages, office hubs and network rooms hold the hardware that supports critical services. For GV.OC-05, record which assets and business functions depend on each site, who operates power, cooling and physical access, and whether a single building hosts more than one critical service. Ask the provider for its own dependency records, such as utility feeds and carrier entry points.
Cloud hosting providers
Infrastructure, platform and managed database services from a cloud provider can sit under several business services at once. Inventory the accounts, regions and managed services each critical service uses, then note which of them have no secondary region or documented export path. Confirm the provider's shared responsibility boundaries in writing so the inventory matches what the contract actually covers.
SaaS and managed service providers
Identity providers, ticketing tools, payroll platforms and outsourced monitoring often carry more operational weight than their license cost suggests. Record each provider against the processes it supports, the data it holds and the fallback if it is unavailable for an extended period. Managed service providers also depend on their own suppliers, so ask which of those are needed to keep your service running.
Network carriers and connectivity
Internet transit, private circuits, DNS hosting and remote access links are dependencies that many inventories leave out. Map which carriers and circuits serve each site and cloud connection, and check whether two circuits share a physical route or a single upstream provider. Flag any path where a carrier outage would isolate a critical service even though the service itself remains healthy.
Key suppliers whose outage halts services
Some suppliers are not technology providers at all, such as a payment switch, a specialist engineering firm or a sole-source hardware maker. Identify those whose failure would stop a critical service within the time the business can tolerate, using results from business impact analysis. Record these as potential single points of failure and confirm with each one what it would take to restore supply.
Inventory by service or by provider
A service-based inventory lists each critical service and every external resource it needs, which makes outage analysis direct but repeats shared providers. A provider-based inventory lists each supplier once and links it to services, which shows concentration risk but needs maintenance when services change. Pick one primary view, then cross-reference it, and confirm which view the auditor or customer expects before building the records.
How an assessor tests the dependency inventory
The assessor starts by reading what the organization says it depends on. This usually means the dependency register or external resource inventory, the asset inventory it should reference, network and data flow diagrams, cloud account listings, hosting and colocation contracts, and any business continuity plan that names facilities or providers. The assessor checks whether the documents agree with each other and whether each entry has an owner, a description of the business function it supports, and a last-reviewed date.
- Missing categories: the register covers hosting providers but omits facilities, telecom carriers, identity services or software-as-a-service tools that hold regulated data.
- Stale entries: a provider appears in the register but the contract it refers to has expired or changed hands.
- Unlinked records: dependencies are not tied to the assets or business functions they support, so the register cannot show what fails if a provider does.
- No review record: the document has no version history or approval showing that anyone has reviewed it.
- Contradictions: the continuity plan names a backup data center that the inventory does not list.
Before the walkthrough, confirm that every document the organization cites is current and that the register's scope matches the systems the assessor will sample.
Interviews test whether the inventory matches how the business actually runs. The assessor speaks with the people who operate or depend on key services, such as platform engineers, facilities managers, procurement staff and application owners. They ask what each service relies on, how the team learned of the dependency, and what would happen if it stopped working. Answers that differ from the written inventory are the most useful findings an assessor can record.
- Shadow dependencies: a team uses a free-tier SaaS tool or a personal cloud account that procurement never saw.
- Vague ownership: the owner named in the register says they have never managed the provider.
- Unknown failover: staff describe a backup path that no document or test confirms.
- Facility blind spots: the operations team knows that a rack depends on a single power feed or building, but the register does not.
- Outdated knowledge: the person who understood a dependency has left and no one has taken over the record.
Before interviews, ask for a list of interviewees and confirm that each one can speak to a specific service in the register.
Sampling tests whether individual dependency records hold up when checked against the asset inventory and other system records. The assessor selects a set of external dependencies, often from the highest-impact services first, then traces each one forward to the assets it supports and back to the contract, configuration or monitoring data that proves it exists. The sample size and selection method should be agreed in advance and recorded in the assessment plan.
- Orphaned dependencies: a provider record has no linked asset, so the link between the supplier and the service it supports cannot be shown.
- Asset gaps: a system in the asset inventory has no recorded hosting provider, facility or upstream service.
- Conflicting locations: the register says a workload runs in one region while the asset record or cloud console shows another.
- Monitoring gaps: a dependency has no health check, status feed or alert, so the organization would not learn of its failure quickly.
- Expired evidence: the contract or service level document attached to a record is out of date.
Ask which records the organization expects to be sampled and make sure each selected record can be traced to an asset in the inventory system.
The walkthrough follows one dependency that the organization has flagged, or that the assessor suspects, from the business service it supports through to the provider and the facility beneath it. The assessor asks the organization to explain how the flag was decided, what alternatives exist, and whether any test has shown that the service survives the loss of that dependency. The aim is to see whether the single point of failure review is a working process or a list that nobody revisits.
- Undocumented criteria: the organization cannot explain why some dependencies are flagged and others are not.
- Sole provider without review: a critical service depends on one cloud region or hosting company, and no one has reviewed that decision since it was made.
- Untested recovery: the stated failover has never been exercised, or the last exercise is undocumented.
- Unresolved actions: a previous review identified a risk and the follow-up action has no owner or due date.
- Concentration hidden by sub-providers: the primary provider appears diverse, but its own hosting or network carrier is the same as the backup's.
Before the walkthrough, ask the organization to choose the dependency it considers most critical so the assessor can trace it end to end.
Implementing the external dependency inventory step by step
This sequence turns the critical services named in GV.OC-04 into a maintained inventory of the external providers, facilities and links they depend on, with single points of failure flagged and owned.
Confirm the critical services from GV.OC-04
Start from the list of objectives, capabilities and services that customers and other external stakeholders rely on, as recorded for GV.OC-04. Business continuity, operations and service owners confirm which services are in scope and which ones carry the highest impact if disrupted. Record each service with its name, business owner and the recovery objectives already agreed for it. The step is complete when every in-scope service has a named owner and a signed-off entry in a single register that the inventory will reference.
Enumerate providers and facilities for each service
For each critical service, the technology and operations teams list everything it runs on or depends on outside the organization's direct control. This includes data center and office facilities, cloud hosting regions and accounts, managed service providers, software-as-a-service platforms, network carriers, payment or identity services and key subcontractors. Interview the people who operate each service, then check the list against contracts and cloud billing records. The output is a provider and facility list per service, with the contract or agreement reference for each entry.
Link each dependency to assets and business functions
Connect every external dependency to the internal assets that rely on it, such as applications, databases, network segments and endpoints, and to the business functions they support. Asset records from the organization's asset management process are the natural source, and a self-hosted CMDB or asset tool can hold the links if the organization already uses one. Where an asset has no recorded owner or location, resolve that before continuing. The check is that each dependency points to at least one asset and one business function, so an outage at a provider can be traced to the work it stops.
Flag single points of failure
Review the linked dependencies to find where one external provider, facility, region or connection is the only route for a critical service. Look for single cloud regions, sole network carriers, one identity or DNS provider, and vendors with no documented alternate. Mark each candidate as a single point of failure, record the impact described by the service owner, and note whether a fallback exists and has been tested. Illustrative example: a payroll service hosted in one cloud region with no documented failover would be flagged, with its owner recording the recovery objective it must meet.
Assign owners and record evidence
Give each external dependency an internal owner who is accountable for the relationship, the contract terms and the fallback plan. Owners confirm the entries in their area and store the supporting evidence, such as contracts, service descriptions, facility records and any resilience test results, where the assessor can find them. The step is complete when every dependency and every flagged single point of failure has one named owner and a linked evidence reference. Ask the organization's compliance team which evidence format it needs for the assessment.
Set the review cadence and change triggers
Agree how often the inventory is reviewed and which events force an earlier review, such as a new provider, a migration to another region, a contract renewal or a serious incident involving a supplier. Record the cadence and triggers in the policy or procedure the organization already uses for asset and supplier management. Confirm the interval with the governance body, because the appropriate frequency depends on how quickly the organization's dependencies change. The output is an approved review procedure and a dated first review.
Feed the inventory into monitoring and supplier governance
Connect the dependency inventory to the processes that act on it: supplier due diligence, contract reviews, monitoring of external service providers and incident response planning. Where the organization runs self-hosted tooling, such as a GRC platform to hold the register or a monitoring platform to watch critical providers, configure those systems to read from the inventory. Confirm with the owners that each flagged single point of failure appears in the risk register with a treatment decision. The step is done when a change in the inventory produces a visible task in those processes.
Assessor test approach, evidence requested and common findings
This table walks through how an assessor would test GV.OC-05, the evidence they would ask for at each step, and the findings that appear most often in dependency inventories. Read it top to bottom as a test plan, then use the findings column to check your own records before the assessor arrives.
| Test step | Evidence requested | Common findings |
|---|---|---|
| Confirm the inventory exists and has an owner | A dated dependency register with a named owner, a review date and the scope it covers (facilities, cloud hosting, managed services, key suppliers) | Register is a spreadsheet last edited long ago, or no one is named as accountable for keeping it current |
| Check coverage against business functions | Mapping from each dependency to the assets and business functions it supports, traceable to the asset inventory | Cloud accounts or data center colocation appear, but the business service they support is not recorded |
| Sample facilities and hosting providers | Contracts, data center location records, provider region or zone details and the hosting arrangement for a sample of systems | Dependency lists name a provider but omit the region, availability zone or secondary site in use |
| Review single point of failure records | Documented analysis of external dependencies whose failure would stop a critical service, with the reasoning for each entry | No single point of failure analysis exists, or it covers internal components only and skips external providers |
| Verify the link to resilience objectives | Recovery objectives or business impact results for the services that depend on each flagged external resource | Flagged dependencies have no recovery expectation, so the team cannot say whether a provider outage is tolerable |
| Test whether the register is kept current | Change records showing new or retired dependencies added after cloud migrations, acquisitions or supplier changes | Shadow SaaS and other unapproved services are used by teams but never entered in the register |
| Confirm the information is communicated | Evidence that the dependency picture reaches risk owners and the teams that run critical services, such as meeting minutes or report extracts | Inventory is held by one team and not shared with continuity, procurement or incident response staff |
| Check the inventory is tooled or traceable | Export from the asset or configuration tool, or a documented manual process with a periodic reconciliation | Manual entries drift from what discovery tools or cloud consoles actually show |
Evidence that passes a GV.OC-05 review
An assessor testing GV.OC-05 looks for records that show the organization knows what it depends on and has a plan for the dependencies that could stop critical services. The six artifacts below work together, so each one should point to the others rather than sit in a separate folder.
Dependency register linked to assets
A register that lists each external resource the organization relies on, such as facilities, cloud hosting, network carriers and managed services, and ties every entry to the assets and business functions it supports. Check that each row names an owner and that the links resolve to current asset records. Review the register after every material change to hosting or sourcing, and at least once a year in between.
Provider list with service mapping
A list of each external provider, the service it delivers, the contract or agreement that governs it, and the business process that depends on it. Assessors use it to confirm that no critical service relies on an unnamed supplier. Confirm that contacts, contract end dates and data locations are current, and that the list matches what finance and procurement show as active.
Single point of failure register
A register of external dependencies whose failure would interrupt a critical service with no fallback, along with a named owner, the mitigation chosen, and the status of that mitigation. A single cloud region, one carrier or one hosting facility are typical entries. Each entry should record the decision taken, such as accepting the risk, adding a second provider or building a tested failover, and the date it was last reviewed.
Facility and hosting region records
Records of the physical locations and cloud regions where systems and data reside, including primary and recovery sites and the provider that operates each one. These records show whether a single site supports several critical services. Keep them aligned with infrastructure-as-code definitions, backup targets and DR runbooks, and recheck them whenever a region is added, moved or retired.
Dependency and outage review minutes
Minutes from the meetings where owners review the dependency register, the single point of failure register and any outage or near miss involving an external provider. The minutes should show who attended, which decisions were made, and which actions remain open with due dates. Assessors often sample these to test whether the register is maintained in practice rather than written once for the audit.
Automated asset discovery exports
Discovery exports from endpoint and inventory tools that confirm the dependency records reflect what is actually running, including software, network interfaces and open services. Compare these exports with the register each quarter to find unrecorded systems or services. Ask your tool vendor to confirm which fields it collects in your deployment before you rely on it as evidence.
What meeting GV.OC-05 costs in money and effort
This table breaks down the cost components of building and keeping a GV.OC-05 dependency inventory, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to scope internal effort against outside help before asking for a written quote. No figures are given because none were supplied for this subcategory.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Inventory tooling | Software vendor or open-source project; internal or partner staff to deploy it | Open-source tools such as GLPI or Wazuh carry no license fee, but hosting, setup and integration still cost money | Number of sites, cloud accounts and suppliers in scope; whether an existing CMDB can be reused |
| Initial dependency mapping | Internal architects, facilities, procurement and business owners; any partner doing fixed-scope work | One-time | How many critical services exist, how well they are documented, and how many interviews are needed |
| Service owner time | Internal business and system owners who confirm facilities, hosting providers and upstream dependencies | Recurring, usually at each review cycle | Frequency of reviews, staff turnover, and how many services change each quarter |
| Engineering integration | Internal platform engineers or a partner, to connect asset data to supplier records | One-time, with occasional rework after major changes | Quality of asset tagging, number of data sources, and whether discovery is automated |
| Evidence upkeep | Internal GRC or compliance staff who keep maps, dependency records and review dates current | Recurring | Rate of change in cloud and facility arrangements; whether records link to assets and business functions |
| External review | Independent assessor or consultant who reviews the inventory against a stated scope | Recurring if the organization commissions reviews regularly | Scope agreed in writing, sampling depth, and whether the review also covers GV.SC supplier controls |
| Auditor sampling | Independent auditor or assessor who selects records to test | Recurring with each assessment cycle | Number of dependencies sampled, quality of evidence, and how quickly records can be produced |
| Remediation of single points of failure | Internal teams and suppliers, for redundancy, contract changes or alternative providers | One-time for each fix, plus ongoing run costs for redundant services | Number of single points found, cost of redundancy, and the criticality of the affected services |
Who owns, who prepares and who assesses dependencies
Your organization owns GV.OC-05 in full. CSF 2.0 expects the outcomes, capabilities and services you rely on to be understood and communicated, and that understanding is a management responsibility, not a task that can be handed to a vendor. Leadership, the business owners of critical services and the people who sign supplier contracts decide which external dependencies matter and what the organization will do when one fails. Those decisions should be recorded with names, dates and the reasoning behind them.
- Dependency decisions: Deciding which facilities, cloud hosting providers and other external services count as critical, and accepting the residual risk of each single point of failure.
- Business context: Confirming which business functions rely on each dependency, since only the business owners can say what an outage costs.
- Communication: Deciding who inside and outside the organization receives the dependency picture, including customers and regulators where contracts require it.
- Review cadence: Setting how often the inventory is refreshed and who approves changes after a new contract or migration.
- Accountability: Assigning a named owner for each dependency record.
Before engaging anyone, confirm that these owners already exist in your governance structure, because a partner cannot make them for you.
An implementation partner such as DeployOpen can prepare the systems and evidence that support GV.OC-05, but it does not decide which dependencies are critical and it does not attest to the result. In practice, the work that is commonly outsourced includes building the inventory, configuring the tools that hold it, and assembling the evidence an assessor will request. Scope, deliverables and timelines should be fixed in writing before work starts.
- Inventory build: Collecting facility, hosting and external service records from your systems and contracts, then linking them to assets and business functions.
- Tooling setup: Deploying and configuring self-hosted asset tools, such as GLPI for asset records or Wazuh for endpoint inventory, inside your own infrastructure.
- Evidence preparation: Exporting inventories, mapping records to the CSF Subcategory and organizing them for review.
- Documentation: Writing procedures for keeping the inventory current and training the staff who maintain it.
- Ongoing support: Refreshing the inventory after changes, if you buy a retainer.
Ask the partner which of these items it will deliver, who on your side must supply source data, and which parts remain your responsibility.
An independent assessor tests whether the dependency records exist, are current and match what the organization actually uses. NIST does not offer certifications or endorsements of CSF-related products, implementations or services and has no conformity assessment program for the CSF, so any formal report on GV.OC-05 comes from an auditor or assessor you engage under a separate, agreed scope. Only that independent party issues a report or certificate, and the implementation partner must stay out of that judgment.
- Sampling: Selecting dependencies and tracing them back to contracts, service records and asset data.
- Interviews: Asking business owners whether they know which external services stop their processes.
- Consistency checks: Comparing the inventory with cloud accounts, procurement records and network data.
- Evidence review: Confirming that single points of failure are recorded and that someone accepted the risk.
- Scope agreement: Defining in advance which framework, report type and period the assessment covers.
Before hiring an assessor, confirm its qualifications, its conflict-of-interest rules and whether it accepts evidence prepared by a third party.
Questions buyers ask about GV.OC-05
What does GV.OC-05 cost to meet?
No fixed price applies to GV.OC-05 itself, because the Subcategory is an outcome your organization achieves, not a product you buy. Cost comes from the effort to build an inventory of external dependencies, map them to assets and business functions, and keep the list current. Your own staff pay for the time spent by business owners, procurement, facilities and IT. An outside partner adds cost only if you scope work to them in writing. Ask any quote to separate one-time discovery work from recurring upkeep, and to state which systems and sites are in scope. The size of your supplier base and how much of it is already recorded in procurement or asset records are the biggest cost drivers.
How long does a GV.OC-05 dependency inventory take?
The duration depends on how many facilities, cloud accounts and providers your organization uses and how well those are already documented. No supplied source gives a standard duration, so treat any timeline you receive as an estimate that depends on your environment. Start by asking the provider or partner to list the phases, the systems in scope and the people they need from your side. A narrow first pass on critical services usually finishes sooner than a full sweep of every supplier. Confirm the timeline against the written scope before work starts.
What does our organization need to provide for this work?
The work needs named people who know the business, not only the technology. You will need access to asset records, cloud account listings, contract registers, facility lists and network diagrams. Business owners must confirm which functions depend on each external resource, and procurement or legal staff should supply the contracts that show who provides what. Expect to resolve gaps where the same service has no clear owner. The Implementation Examples for GV.OC-05 describe documenting external dependencies that could become points of failure for critical services, so involve the people who understand those services.
Can we inventory external dependencies in-house?
Yes, many organizations do this in-house, because GV.OC-05 does not require any specific tool, vendor or outside party. The main question is capacity and independence. Internal teams already know the business, but they may lack time, or they may not challenge assumptions about who depends on whom. An implementation partner can prepare the inventory, the asset linkages and the evidence, but your organization still owns the decisions about which dependencies are critical. Open-source asset tools such as GLPI can hold the records once you decide what to track.
Does NIST certify GV.OC-05 or the CSF?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Showing alignment with GV.OC-05 means documenting your own dependency inventory and evidence, which a customer or assessor may review. If someone offers a NIST certificate for GV.OC-05, ask what body issued it and whether NIST recognizes it. Any independent review of your alignment comes from an assessor you choose, and that assessor's report is their own opinion.
How does GV.OC-05 relate to GV.OC-04?
GV.OC-05 is the reverse of GV.OC-04. GV.OC-04 covers the objectives, capabilities and services that customers and other external stakeholders rely on from your organization. GV.OC-05 covers what your organization itself depends on, such as facilities, cloud hosting providers and other external resources, and flags those that could be single points of failure. Teams usually run both together, because the business impact analysis behind GV.OC-04 shows which dependencies matter most. Keep the two records linked so a change in one supplier updates the critical services it supports.
How do ISO/IEC 27001 Annex A controls 5.3 and 5.8 relate to GV.OC-05?
The ISO/IEC 27001:2022 informative references in the NIST CSF 2.0 Reference Tool map GV.OC-05 to Annex A controls 5.3 and 5.8. Control 5.3 concerns segregation of duties, and control 5.8 concerns information security in project management. These are mappings, not equivalences, so an inventory built for GV.OC-05 does not by itself satisfy either ISO control. Confirm with your ISO certification body how they read the overlap. Evidence for both controls will still need its own review against the ISO requirements.
What should we ask a partner before hiring one for this work?
Ask for a written scope that names the facilities, cloud accounts, providers and critical services covered, plus the deliverables and the dates agreed before work starts. Confirm who owns the decisions about criticality, since the organization keeps ownership of its controls. Ask how the partner will record dependencies, how often the inventory will be refreshed, and whether ongoing support is a separate retainer. DeployOpen plans and prepares systems and evidence in your own infrastructure, but it does not issue audit reports or certifications, so ask any provider to confirm the same distinction.
Where GV.OC-05 programs usually fall short
GV.OC-05 asks the organization to understand the external resources it relies on, from facilities to cloud hosting. The gaps below tend to appear together: the inventory is incomplete, it is not tied to the systems it supports, and it is not reviewed as the environment changes.
Providers recorded only by procurement
Cloud hosting, colocation and managed service contracts often sit in the procurement or finance system and never reach the security team's inventory. A dependency that is paid for but not recorded cannot be assessed for failure impact. Ask procurement for a contract export and reconcile it against the technical inventory, flagging any provider with no owner.
Dependencies not linked to assets
A list of providers is of limited use if it does not show which hardware, software, data and business functions each provider supports. Without that link, a provider outage cannot be traced to the services it breaks. Map each external dependency to the assets and functions it serves, and confirm that every critical service has at least one mapped dependency.
Single points of failure unrecognized
Teams often discover a single point of failure only during an outage, such as one DNS provider, one identity service or one data center used by several critical services. Record where a single external resource carries more than one critical function and document the fallback, if any. Confirm with each owner whether the fallback has been tested.
Stale provider lists
Provider lists age quickly as contracts renew, services migrate and acquisitions add new suppliers. A list that was accurate at the last audit may omit the hosting provider that now stores production data. Set a review trigger tied to contract renewal, change requests and onboarding of new services, and record the date of each review.
Sub-providers hidden behind contracts
A primary provider may depend on its own facilities, networks or subcontractors, and those dependencies usually do not appear in the customer's inventory. When one of them fails, the impact reaches the organization without any warning in its own records. Ask key providers for their material sub-dependencies and whether they are disclosed in contract documents.
Facilities missing from the inventory
Office buildings, data center space, network carriers and power or cooling supply are frequently treated as background rather than as dependencies. Their loss can take down several services at once. Include physical facilities and carriers in the inventory, with the critical services each one supports and the named owner responsible for the relationship.
Using GLPI and Wazuh to evidence dependencies
This sequence shows how an organization can use GLPI asset records and Wazuh Syscollector inventories to link internal assets to the external providers they depend on, producing dependency evidence that supports GV.OC-05. It also sets out the license terms to review and the fit checks to complete before relying on either tool for provider tracking.
Define the dependency record fields
The GRC or asset owner decides which fields each dependency record needs before any tool is configured. Typical fields include the internal asset or business function, the external provider, the type of resource (facility, cloud hosting, network carrier, software service), the owner, and whether the dependency is considered a potential point of failure for a critical service. Agree the field list in writing so the records can be compared over time. The step is complete when the field list is approved and each field has a named owner responsible for keeping it current.
Confirm GLPI fit for asset records
The IT asset manager reviews the GLPI Assets module against the field list from the previous step. GLPI manages computers, monitors, software, network equipment, peripherals, printers, phones and racks, and these can be entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. Confirm whether GLPI's item types and custom fields can hold provider and contract details, or whether that information must sit in a linked record or a separate register. The output is a short written fit note that states which dependency fields GLPI can hold natively and which need workarounds.
Populate asset-linked dependency records
The asset owner links each in-scope GLPI asset, such as a rack, server, network device or licensed software item, to the external provider it relies on, including facilities, cloud hosting and key service providers. Where GLPI does not store a provider relationship natively, the team records it in a controlled register that references the GLPI asset identifier. The step closes when every in-scope asset has either a provider link or a documented reason for having none, and a second person has checked a sample of the entries against the contracts or service documentation.
Collect endpoint and network inventory with Wazuh
The security engineer deploys Wazuh agents to in-scope endpoints so that the Wazuh Syscollector module can collect hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates. These results are stored in the Wazuh indexer and shown in dashboard inventory views and reports. The engineer confirms that inventory data is flowing for each in-scope host and that the hosts match the GLPI asset list. Gaps between the two sources are logged for reconciliation, since they often show assets missing from the CMDB or hosts that were never registered.
Trace external connections to providers
The security engineer uses the Syscollector network interface, open port and service data to identify which internal systems are configured to reach external endpoints, such as cloud management interfaces, hosted services or managed network links. Each finding is matched to a dependency record. Where the inventory shows a connection that no record explains, the owner investigates and either adds a dependency record or documents the connection as unauthorized. The step produces a reconciled list showing which internal assets rely on which external providers, based on both declared and observed data.
Flag single points of failure
The business continuity lead and asset owner review the reconciled dependency list and mark any external provider that supports a critical service with no alternative path, such as one data center, one cloud region or one upstream carrier. Each flag is linked to the business function it affects and to the recovery objectives already set for that function. The output is a short list of flagged dependencies with an owner and a review date agreed by leadership. Leadership sign-off, recorded in the risk register or governance minutes, shows the flags were communicated, which is the outcome GV.OC-05 describes.
Review licenses and confirm the operating model
Before production use, legal or procurement reviews the license terms of each tool. GLPI is licensed under GPL-3.0-or-later and Wazuh's Syscollector and agent components are part of Wazuh, licensed under GPL-2.0-only, so the organization should confirm how these terms apply to its own deployment, modifications and any distribution to third parties. Confirm with the vendors and the organization's counsel rather than relying on this summary. The team also confirms who administers each tool and who maintains the external provider register. The step is complete when a written license and ownership note is filed with the GV.OC-05 evidence.
Retain dependency evidence for review
The GRC lead stores the field list, fit note, reconciled dependency list, flagged single points of failure, leadership sign-off and the Wazuh inventory reports together under the GV.OC-05 control record. The team sets a review cadence agreed with leadership, and records changes to providers, contracts and assets as they occur. An independent assessor can then trace a flagged dependency back to its GLPI asset, its Wazuh evidence and its sign-off. The step closes when the evidence pack can be reproduced from the source systems without manual reconstruction.
How DeployOpen scopes and prepares GV.OC-05 evidence
DeployOpen scopes GV.OC-05 work in writing before any system is touched. The scope names which business services, facilities, cloud accounts, hosting providers, managed services and data flows are in the dependency inventory, who in the organization owns each one, and which outputs will be delivered. Because the topic asks for dependencies on external resources such as facilities and cloud hosting providers, the first decision is the boundary: whether a colocation site, a SaaS identity provider or a managed backup service counts as in scope. Organizations should settle that boundary with their business continuity and procurement leads before the inventory starts, since it determines what the evidence has to cover.
Inside the client's own environment, the inventory is built from systems the organization already runs. In GLPI, the Assets module can hold computers, network equipment, racks and software records, entered manually or pushed by the GLPI Agent through native inventory. In Wazuh, the Syscollector module collects hardware, operating system, installed software, network interfaces, open ports and services from each endpoint into the dashboard inventory views. Those records show what the organization runs and where, but they do not show which outside providers each asset depends on. DeployOpen configures these tools to capture the link between an asset, the business function it supports and the external provider behind it, then reviews gaps with the owners. Clients should confirm that the tools they choose can record that relationship in their own version and that their CMDB or contract register holds the provider data.
The evidence that DeployOpen prepares for GV.OC-05 is a dependency register with named owners, a list of external dependencies flagged as possible single points of failure, and a record of how each flag was reviewed. CISO Assistant can hold the mapping of this evidence to NIST CSF 2.0 and to the informative references NIST lists for GV.OC-05, including SP 800-53 controls and ISO/IEC 27001:2022 Annex A controls 5.3 and 5.8. Clients should confirm the mapping against the current NIST Reference Tool before relying on it. DeployOpen does not issue audit reports, attestations or certifications. Any assessment of whether GV.OC-05 is met is performed by the organization's own reviewers or an independent assessor, who decides what the evidence proves.
