ID.AM-03 Network and data flow maps: requirements and evidence

What ID.AM-03 network and data flow maps require in NIST CSF 2.0

When an audit, a customer questionnaire or a new network project asks whether authorized communication and data flows are documented, the answer points to ID.AM-03. It is a Subcategory of the Asset Management (ID.AM) Category in the Identify Function of NIST CSF 2.0. Its outcome is that representations of authorized network communication and of internal and external network data flows are maintained. NIST's four Implementation Examples cover baselining these flows on wired and wireless networks, flows with third parties, flows for IaaS use, and documenting the ports, protocols and services that authorized systems normally use. The word that matters is *maintained*: a diagram created for one project does not satisfy the outcome on its own.

The risk is straightforward. A communication path nobody has written down is a path nobody reviews. An unknown database replication link, a forgotten VPN tunnel to a supplier or a service account allowed to reach an internal subnet can all widen exposure without any change ticket. Flow maps are also hard to keep current. Firewall rules change, microservices scale, and cloud security groups get edited in consoles, so the documented picture drifts from the live network. Paths to third parties and IaaS providers are often the least visible, because the organization sees its own perimeter but not the provider's internal routing or the supplier's connections into its environment.

To act on this, confirm three things with your own teams. First, who owns each flow map and how often it is reconciled against firewall, routing and cloud configuration exports. Second, whether the expected ports, protocols and services for each authorized system are recorded, so that unexpected traffic has a baseline to be compared against. Third, whether third-party and IaaS connections appear in the same maps as internal segments. Any recurring reconciliation effort, and any tooling that collects flow data, should be sized in a written scope. The organization owns the maps and the decisions they support. An implementation partner can help build and evidence them, but an independent auditor is the party that tests them.

Which networks, flows and third parties fall under ID.AM-03

ID.AM-03 applies wherever authorized communication and data flows exist, so the first job is deciding the boundary. The cards below cover the scoping choices that most often change how much mapping, validation and evidence an organization must produce.

Production and non-production networks

Development, test, staging and disaster recovery networks often carry copies of production data and connect back to production services. Each one needs its own communication baseline, because a test environment that reaches live APIs or databases creates flows that the production map alone will not show. Check whether non-production networks are in scope, whether they receive production data, and which paths connect them to production. The workload grows with every environment that touches live data.

Wireless networks

Wireless access points, guest networks and mobile device connections create communication paths that wired diagrams often omit. NIST's Implementation Examples for ID.AM-03 explicitly address baselining flows on wired and wireless networks, so both must be documented. Ask whether each SSID maps to a segment, which services it can reach, and how client devices enter the trusted network. Wireless controllers and their management channels also belong in the map.

OT and industrial segments

Operational technology networks, such as building systems, production lines and sensor gateways, often run legacy protocols and vendor remote access paths. Their flows are usually poorly documented and change rarely, so they tend to drift from the record without anyone noticing. Confirm which OT segments connect to IT networks, which conduits carry data upward, and which vendor sessions reach them. Passive discovery on OT networks may need to be scheduled and approved by operations staff.

IaaS accounts and virtual networks

Cloud accounts, virtual networks, subnets, security groups and peering links change through infrastructure-as-code pipelines, so a static diagram goes stale quickly. NIST's Implementation Examples call out IaaS use directly. Map flows across each account and region, including traffic between accounts and into on-premises networks. Export security group and route configurations as evidence, and confirm who may change them and how those changes are logged.

SaaS and API integrations with third parties

Third-party SaaS connectors, webhooks, payment gateways and API keys move data outside the organization's network boundary. These flows are authorized by contracts and integration settings rather than by firewall rules, so they are easy to miss. For each integration, record the data sent, the direction, the endpoint, the authentication method and the business owner. Revisit the list whenever a supplier adds a connector or a team enables a new integration.

Data classes that cross each boundary

A flow map is more useful when each arrow states what data it carries. Personal data, payment data, health records and controlled unclassified information each bring different obligations, and they may be restricted from certain destinations. Pair each boundary crossing with the data class from the data inventory, such as those covered by ID.AM-07. Ask which flows carry regulated data, which ones are encrypted in transit, and which ones have no documented purpose.

How an assessor tests ID.AM-03 network and data flow maps

This table walks through the steps an assessor typically takes to test ID.AM-03, from reviewing the diagrams themselves to sampling real flows and checking third-party and IaaS paths. Read each row as a test step, the evidence it draws on, and the gap that most often appears at that step.

Test step	What the assessor does	Evidence requested	Common finding
Review the diagrams	Checks that network and data flow maps exist, cover in-scope environments and show who owns and approved them	Current diagrams with version, date, owner and approval record	Diagrams with no date or owner, or a single file that predates recent network changes
Compare against firewall rules	Traces each documented flow to the permit rules that allow it and looks for rules with no documented business purpose	Firewall policy export, rule descriptions and change tickets	Broad any-to-any rules or permit rules that match no diagrammed flow
Compare against routing and segmentation	Confirms that documented paths between zones match the routes and segment boundaries in the live network	Routing tables, VLAN or segment inventory and zone definitions	Routes or bridges between zones that the diagram does not show
Check cloud network configuration	Reviews virtual networks, security groups, peering and gateways against the IaaS flows drawn on the map	Cloud network configuration exports and account or subscription list	IaaS paths, peering links or public endpoints missing from the diagrams
Sample flows end to end	Picks a sample of documented flows and confirms the ports, protocols and services used match what the map states	Flow logs, session records or packet capture summaries for the sampled flows	Documented ports that differ from observed traffic, or services running on non-standard ports
Check third-party and external flows	Confirms that data flows to suppliers, SaaS providers and APIs appear on the map with direction and data type	Supplier list, integration inventory and contracts or data processing terms	Outbound SaaS or API connections in logs that no diagram or supplier record covers
Test for undocumented egress	Reviews outbound traffic from sensitive zones for destinations that have no documented purpose	Egress logs, proxy or DNS query records and an explanation for each destination	Outbound connections to unexplained hosts, or no egress logging in place
Confirm review and maintenance	Checks that the maps are reviewed when networks or data flows change and that the review leaves a record	Change records linked to map updates and dated review sign-offs	Maps last reviewed before major migrations, with no link between changes and updates

How to baseline network and data flows without guessing

A baseline of authorized network communication and data flows is built from evidence gathered in a discovery phase, not from the architecture diagram a project team drew at launch. The Implementation Examples for ID.AM-03 describe baselining communication and data flows across wired and wireless networks, with third parties and for IaaS use, and they point to documenting the ports, protocols and services that authorized systems normally use. Expect that discovery work to come before any diagram is drawn, and plan time for it in the scope you agree with an implementation partner. The baseline draws on three sources, and each one is wrong in a different way when used alone. Observed traffic comes from firewall and network sensor logs, flow records and, where deployed, intrusion detection output such as the EVE JSON records that Suricata writes for flows and protocol transactions like DNS, TLS and SSH. Configuration exports come from firewall rule sets, load balancers, cloud security groups and routing tables. Application owner interviews explain why a flow exists, who depends on it and whether it is still needed. Traffic shows what happens, configuration shows what is allowed, and owners explain what is intended. Where the three disagree, the disagreement is the finding: a rule that never matches may be dead, and a flow that appears in logs without a rule may be an unauthorized path or a forgotten integration.

Reconcile the sources in a single register before drawing anything. For each flow, record the source, destination, port, protocol, service, data classification, owner and the evidence that supports it, then mark it as confirmed, undocumented, unexpected or retired. Treat every unexpected flow as an open question for the owner and the security team, not as something to add to the approved baseline by default. Ask your partner and your own network team to confirm which log sources cover which segments and time windows, because a baseline built from a two-week capture will miss monthly batch jobs and disaster recovery paths. The register, not the diagram, is the document an assessor will test against.

Implementing ID.AM-03 step by step

This sequence turns ID.AM-03 from an idea into maintained records: a defined scope, collected configuration and traffic data, a baseline of authorized communication, documented expected ports and services, mapped third-party and IaaS flows, named owners, and maps kept under change control. Each step ends with an output you can show an assessor.

Define the scope of network and data flow mapping
Start by listing which networks, segments, cloud accounts, data centers and business applications the maps must cover, and which systems sit inside each boundary. Record the scope in a short document signed off by the owner of the network and the owner of the business service. Include wired and wireless networks, because the Implementation Examples for ID.AM-03 cover both. The step is complete when every in-scope segment and application has a named entry in the scope register and any exclusions carry a written reason.
Collect configuration and traffic data
Gather the raw evidence that describes how systems actually talk: firewall and gateway rule sets, VLAN and routing configuration, cloud security group and network policy exports, and flow records from switches, routers or network sensors. For self-hosted environments, an IDS or IPS such as Suricata can write flow and protocol transaction records to EVE JSON for later analysis. Store exports with timestamps and the name of the person or tool that produced them. The step is complete when each in-scope segment has at least one configuration source and one traffic source on file.
Build the authorized communication baseline
Compare the collected traffic against the intended design. Identify which source and destination pairs, protocols and ports are expected for each business service, and separate authorized flows from unexplained ones. Review unexplained flows with the system owner, then either document them as authorized with a justification or raise them as findings for investigation. The output is a baseline table of authorized communication for each service. The step is complete when every observed flow in scope is either authorized with a recorded reason or logged as an open finding.
Document expected ports, protocols and services per system
For each authorized system, record the ports, protocols and services it normally uses, the direction of each flow and the business purpose behind it. This is the level of detail the ID.AM-03 Implementation Examples describe when they refer to documenting what authorized systems normally use. Keep the record in one place per system so that a deviation is easy to spot. The step is complete when every in-scope system has an entry that an engineer outside the project could read and check against a live rule set.
Map third-party and IaaS data flows
Extend the baseline to flows that leave your boundary: connections to SaaS providers, payment or data processors, managed service providers, APIs and IaaS-hosted workloads. For each flow, record the external party, the data categories carried, the endpoints, the protocol and the contractual or technical reason for the connection. Confirm with the provider or the cloud configuration which network paths are in place, because provider-side controls are often documented separately. The step is complete when each external connection has a flow entry linked to a supplier or service record.
Assign owners and set a review cadence
Name one owner for each map, usually the owner of the network segment or service, and a second person who can check the content. Agree a review cadence in the governing policy, and define the events that trigger an earlier review, such as a new service, a firewall change or a supplier onboarding. Record owners and cadence in the asset register so they are visible to assessors. The step is complete when every map has an owner, a reviewer and a written trigger list.
Store the maps under change control
Place the maps in a versioned, access-controlled repository such as a wiki or documentation platform with page history. Each change should record what changed, when, and by whom, and the previous version should remain recoverable. Tie significant changes to the change management process so that a new flow approved in a change ticket also updates the map. Retain the history so that an assessor can see the baseline as it stood on a given date. The step is complete when a sample change can be traced from the change ticket to the updated map and the prior version.

Evidence that satisfies ID.AM-03 and keeps it current

An assessor testing ID.AM-03 wants to see a documented picture of authorized communication and data flows, and proof that the picture matches the live environment. The cards below cover the artifacts that carry that proof and the routines that keep them accurate between assessments.

Dated network and data flow diagrams

Diagrams show which segments, zones, hosts and cloud accounts communicate, and which data moves between them, including the direction of each flow. Every diagram needs a version number, a date, and a named owner so an assessor can tell which picture was current at a given point. Check that the diagrams cover internal flows, flows to external parties, and flows inside IaaS accounts, not only the perimeter. A diagram that shows only the firewall boundary does not show the internal flows ID.AM-03 asks about.

Flow register with ports and protocols

A flow register is a table with one row per authorized flow. Each row records the source, destination, port, protocol, service, data classification and business purpose. The register is what the Implementation Examples describe as documenting the ports, protocols and services that authorized systems normally use. Confirm that every rule in the firewall and cloud security groups traces back to a register row, and that every register row has a corresponding rule.

Third-party and IaaS flow inventory

This inventory lists every flow that leaves the organization's control, including connections to SaaS providers, payment processors, managed service providers and cloud-hosted workloads. For IaaS, record the account, virtual network, subnet and peering or transit links, because cloud flows often change without a ticket. Ask the owner of each external connection to confirm the endpoints and the data types. Gaps usually appear where a business unit set up an integration directly, so compare the inventory against cloud billing and API gateway logs.

Approval records for authorized flows

Each flow in the register needs evidence that someone with authority approved it before it went live. The approval record names the approver, the business justification, the data involved and the review date. Store the approval next to the register row, not in an email thread that cannot be found later. Confirm that approvers are not the same people who configured the rule, where the organization's segregation policy requires separation.

Change records showing updates

Change records prove that the diagrams and register moved when the network moved. Each firewall rule change, new cloud connection, or retired service should reference the register row it creates, modifies or removes. Pull a sample of recent changes and check that the matching register entry was updated on the same day or in the same change ticket. Missing links between change tickets and the register are the most common reason a flow map fails testing.

Live flow discovery and periodic review

Between audits, compare the documented flows against observed traffic. Flow logs from firewalls, network sensors and cloud flow logs can show communication that no register row explains. Suricata's EVE JSON output can record flow and protocol transactions such as HTTP, DNS, TLS and SSH for analysis, and OPNsense can send alerts to syslog in that format. Set a periodic review cycle with a named owner, and record each review as evidence. Ask the team to confirm the review interval in writing, since no assessor-approved interval is set by the framework.

What mapping network and data flows costs

This table breaks down the cost components of documenting ID.AM-03 network and data flow maps, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No price or duration is given because none is supplied for this topic, so use the drivers to shape a written scope and quote.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Discovery tooling or licenses	Tool vendor or open-source maintainers; internal platform team runs it	Licenses recur; open-source tooling has no license fee but still needs hosting and staff time	Number of network segments and cloud accounts; self-hosted open-source flow and log collection removes license spend but not operating effort
Engineering and architect time	Internal architects or an implementation partner building the baseline	One-time for the initial baseline, recurring for changes	Network complexity, number of wired and wireless segments, and how much existing documentation is reusable
Owner interviews	Internal application, network and data owners	One-time per flow set, recurring at each review	How many data flows cross teams, and whether owners know which ports, protocols and services their systems normally use
Third-party and IaaS mapping effort	Cloud administrators, supplier contacts and internal reviewers	Mostly one-time, recurring whenever a supplier or cloud service changes	Count of external connections, supplier cooperation in sharing their data flows, and how often cloud network rules change
Evidence upkeep	Internal document owners and version control administrators	Recurring	Frequency of network change, and whether diagrams and port lists are kept under version control with change history
Auditor sampling	Independent auditor or assessor, billed by the assessment firm	Recurring with each assessment cycle	Number of flows sampled and how completely the records match live configuration; ask the auditor for its sampling approach before work starts
Remediation of undocumented flows	Internal engineers, possibly partner staff	One-time per discovered gap	Number of undocumented or unauthorized flows found during baselining and how many need configuration changes

Who maps flows in-house, with a partner, and at the auditor

Your organization decides which network communication and data flows are authorized, and it is the only party that can accept the map as its own record. ID.AM-03 asks for representations of authorized communication and of internal and external data flows to be maintained, so the business justification for each flow has to come from the people who run the systems and the people who depend on them.

Authorization decisions: named owners approve each flow, including its purpose, source, destination and data category.
Expected ports and services: application owners state which ports, protocols and services each authorized system normally uses.
Third-party and IaaS flows: owners of supplier relationships and cloud accounts confirm the external endpoints they have contracted for.
Change approval: new or removed flows pass through your change process before the map is updated.
Sign-off record: a dated approval with a named accountable person, kept with the diagram.

Confirm that the approval workflow names a person, not a team mailbox, for each flow class, and that the approver can explain each entry without relying on the partner.

Where flow maps usually fail and how to close the gap

Most flow maps fail for the same few reasons: they describe an older environment, they skip paths that were never built on premises, and they have no one accountable for keeping them true. Each card below pairs one failure with a closure step you can check against your own environment before an assessor does.

Diagrams that predate the last migration

A map drawn before a data center move, network re-IP or application re-platform still shows flows that no longer exist and omits the ones that replaced them. ID.AM-03 asks for representations that reflect current authorized communication, so a stale diagram fails on its face. Closure step: compare each map against a fresh capture of firewall rules, load balancer pools and DNS records, then record the date of the last validation on the diagram itself. Ask your team which migrations since the last review changed a flow, and re-baseline those segments first.

Missing IaaS and SaaS paths

Cloud-hosted workloads often talk to managed databases, identity providers, object storage and SaaS APIs through paths that never appear on a rack-and-cable diagram. The NIST implementation examples for ID.AM-03 explicitly call out flows for IaaS use, so these paths belong in scope. Closure step: pull cloud flow logs, security group and virtual network rules, and egress allowlists for each account, then map every external endpoint those rules permit. Confirm which of these paths carry regulated data before deciding how deeply to document them.

Undocumented third-party data sharing

Flows to payroll providers, analytics vendors, support tools and managed service providers are often set up by business teams and never reach the network diagram. Without them, the map shows a closed environment that does not exist. Closure step: reconcile your supplier services inventory and outbound proxy or firewall logs against the flow map, then list each third party with the data categories sent, the direction, the protocol and the contract that governs it. A flow with no named owner or no contract is a finding in its own right.

Wireless and OT segments left out

Wireless access points, building controls, industrial controllers and engineering workstations are commonly drawn as a single cloud or omitted entirely because they sit outside the IT team's tooling. NIST's examples for ID.AM-03 cover both wired and wireless networks, so a map that stops at the corporate LAN is incomplete. Closure step: obtain the wireless controller configuration and a site survey of SSIDs, then document OT zones with their boundary devices, allowed conduits and any remote vendor access. Confirm the ownership of each segment with its operators before drawing it.

Flows with no named owner

A flow that no one owns is rarely reviewed, so it outlives the project that justified it. Flow maps also decay fastest when no one is accountable for approving a new connection or retiring an old one. Closure step: assign each flow an owner who can state its business purpose, the expected ports, protocols and services, and the review date. Record the approval in your change process so that a new firewall rule cannot appear without a corresponding map entry, and retire flows whose owner cannot be identified.

Maps stored where no one updates them

A diagram saved as a static file on a shared drive is hard to version, hard to review and easy to leave behind. ID.AM-03 expects the representation to be maintained, which means a process and a location that show when it changed and who approved the change. Closure step: keep the map and its flow register in a wiki or documentation platform with version history, so reviewers can compare revisions and see who changed a flow. Test the process by picking one recent network change and confirming the map reflects it within your normal change window.

Questions buyers ask about ID.AM-03 cost, effort and scope

How long does it take to map network and data flows?

The duration depends on the size and age of the environment, not on a fixed rule, and no supplied figure sets a standard timeline. The main drivers are the number of network segments, how many systems have undocumented connections, whether wired and wireless networks are both in scope, how many data flows cross to third parties or run in IaaS, and whether existing diagrams are current. An organization with accurate architecture records and a small estate will finish far sooner than one with years of undocumented change. Ask any partner for a phased plan with a written scope and deliverables before work starts, and confirm which networks, cloud accounts and external connections are included.

Can our team map network and data flows without outside help?

Yes, in most cases an internal team can do this work, provided it has access to firewall rules, routing and cloud network configuration, and the people who own each application. ID.AM-03 asks the organization to maintain an accurate representation of authorized communication and data flows, and the organization owns that result. Outside help becomes useful when the team lacks time, when flows are hard to trace across cloud and on-premises boundaries, or when an independent reviewer should check the baseline. Whatever the approach, the output must be kept current, so plan who maintains the maps after the first pass.

What does the work need from engineers and system owners?

Mapping requires engineers who can read firewall policies, routing tables, DNS and VPN configurations, and cloud security groups, and business owners who can confirm why each flow exists. Engineers typically export configurations and capture traffic baselines, while owners validate that each path is authorized and list the ports, protocols and services their systems normally use. Expect the work to surface flows nobody can explain, which then need an owner decision. Ask for a named contact on each side before the engagement starts, because delays usually come from waiting for owner confirmation rather than from technical discovery.

Does a managed partner need to be involved?

A partner is not required by NIST, but one can shorten discovery and add an independent view. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, and can prepare network and data flow documentation as part of a fixed-scope engagement. It does not issue audit reports or certifications, and ID.AM-03 is evidenced to an assessor by the organization's own records. Compare partners on how they handle authorized flow baselines, third-party and IaaS paths, and handover to your team, and request the written scope before comparing quotes.

What does a quote for this work include?

A quote should list the components priced separately: discovery of configurations and traffic, validation with owners, documentation of flows and their ports, protocols and services, and handover. Ask whether third-party connections, IaaS accounts and wireless networks are included, and whether updates are covered after delivery. Costs usually rise with the number of environments, the volume of undocumented flows and the depth of owner review. DeployOpen does not publish a price list, and a quote follows from the written scope.

Does NIST certify that our network and data flow maps comply with CSF 2.0?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The Cybersecurity Framework is voluntary for most organizations, so any assurance of ID.AM-03 comes from your own documented evidence or from an independent assessor you engage. Your customers or regulators may ask for that evidence in a specific format, so confirm which report or attestation they expect before you start.

What should we keep current once the maps are finished?

Keep the maps tied to change management, so every new connection, cloud account, third-party link or firewall rule change updates the flow records. Review the baseline on a schedule you set and compare it with observed traffic, such as alerts from a network intrusion detection system like Suricata, which can write JSON event records to log tools. Store the maps in a versioned wiki or document system so you can show what changed and who approved it. Confirm with any partner whether ongoing support is offered as a retainer and what it covers.

Open-source tools that support flow evidence

Observed traffic can be evidenced with OPNsense and Suricata, both open source. OPNsense, licensed under BSD-2-Clause, ships with an intrusion detection and prevention system built on Suricata, which is licensed under GPL-2.0-only. Suricata's EVE output writes JSON records for alerts, flows, and protocol transactions such as DNS, TLS, SSH and SMB, and OPNsense can forward alerts to syslog in EVE JSON format. For ID.AM-03, the flow and protocol records are the useful part: they show which hosts actually talk to which services on which ports, which you can compare with your documented expectations. Confirm which sensor positions in your environment see traffic on the segments and cloud paths your map covers, because a sensor that sees only the perimeter will not show east-west or IaaS flows. Also confirm where EVE files are stored, how long they are retained, and whether your log management tool can split the flow and alert types into separate indexes.

Visibility records do not replace an authoritative map, so the map itself needs version control and permissions. XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom, and lets reviewers compare any two versions and roll back. BookStack (MIT) assigns abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level. Either tool can hold the authorized communication matrix, data flow diagrams and the list of expected ports, protocols and services, with the change history an assessor will ask to see. Decide who may approve a change to an external flow, such as a new third-party API, before you configure the permissions. Confirm the license terms and hosting requirements with each vendor, and check that your chosen tool's version history can be exported or retained independently of the application if your evidence policy requires it.

Treat the tools as evidence sources, not as proof of compliance. An assessor will compare the documented map against what the sensors observed, so plan a recurring review that records each discrepancy, its owner and its resolution. Keep a dated export of the map alongside the Suricata or syslog records from the same period. The tools only show what they were configured to see, so the reader should confirm sensor coverage, rule update processes for the Emerging Threats and Abuse.ch rulesets used by OPNsense, and the access controls on the log store before relying on the output. If the evidence will support an external assessment, agree with the independent assessor in advance which records they will accept and in what format.

How DeployOpen works on this

DeployOpen works on ID.AM-03 by scoping the communication paths and data flows of the systems it deploys, then documenting them as maintained records the organization owns. The organization stays responsible for its controls, while DeployOpen prepares the systems and evidence an independent assessor will review.

How we scope

Engagements are fixed-scope, with the flows, networks and cloud accounts in scope written down before work starts.
The written scope names internal segments, wireless networks, third-party connections and any IaaS environments that carry authorized traffic.
Scope also records which ports, protocols and services each authorized system is expected to use.

How we build

Baseline traffic on the deployed platforms and compare it with the flows the organization says it intends to allow.
Configure intrusion detection on firewalls where the platform supports it, such as Suricata rulesets on OPNsense, and confirm alerts reach logging.
Map external data flows to named third parties, noting the data type and transport for each connection.

How we hand over

Deliver a network and data flow diagram set, with a versioned register of authorized communication paths and their owners.
Store documentation in version-controlled wiki tools such as XWiki, so changes show what changed, when and by whom.
Provide the change procedure that keeps flow maps current when new services, vendors or cloud accounts are added.

How we support

Ongoing support, upgrades and periodic re-baselining of flows are available as a retainer after handover.
Ask the organization's independent assessor which evidence formats and review cadence they expect before the scope is finalized.
Confirm with your assessor and framework mapping owners which informative references apply to your environment.