Safeguard 3.8 Document data flows: requirements and evidence

What Safeguard 3.8 document data flows requires and why assessors check it

Safeguard 3.8 asks the enterprise to document how its data moves, including flows to and from service providers, and to base that documentation on the data management process. The documentation must be reviewed at least once a year and after significant enterprise changes. When an audit or customer questionnaire asks where sensitive data goes, this Safeguard is the record that should answer it. It is an IG2 and IG3 Safeguard rather than an IG1 one, and CIS places it in the Identify security function and the Data asset class, so it belongs to the planning layer of the program rather than the day-to-day hygiene baseline.

The risk is easy to state. If nobody can say which systems receive sensitive data, unknown exfiltration paths and unmanaged provider access tend to appear in the places nobody reviewed, such as a reporting export, an analytics connector, a backup replica in another region or a support tool with bulk access. The difficulty is that flows are spread across application teams, SaaS subscriptions bought outside IT, and integrations built by engineers who moved on. No single system holds the full picture, which is why the documentation has to be assembled from the data inventory and the data management process rather than drawn once from memory.

Assessors check two things. First, that a current data flow record exists and was reviewed within the last 12 months, since the assessment specification scores the Safeguard as failing otherwise. Second, that the record covers flows to external enterprises, measured by comparing documented flows with the flows the assessor can find. Before starting, confirm with your assessor how they will select external flows and which evidence they accept, such as integration configurations, provider contracts or network egress records. Safeguards 3.1 and 3.2 are prerequisites because they supply the data categories and inventory that each flow must reference.

Which data flows and parties fall in scope for Safeguard 3.8

Safeguard 3.8 is only as complete as the boundary you draw around it. The cards below cover the decisions that most often change the size of the documentation: which data classes are in, how internal and external flows are separated, where data physically goes, and which informal channels get left out.

Data classes drawn from the inventory

Start with the data classes recorded in the data inventory from Safeguard 3.2, then filter them by the classification labels from Safeguard 3.7. Sensitive classes need every flow documented, while lower-sensitivity classes can be grouped. Confirm with the data owners that the inventory is complete, because a flow cannot be documented if its data class was never listed. Record which classes were excluded and why, so an assessor can see the boundary was a decision rather than an omission.

Internal system-to-system flows

Application-to-database, service-to-service and batch jobs inside your own environment are flows too. They are easy to miss because no contract or vendor names them. Map them from integration configuration, API gateways and network rules rather than from memory. Check that each flow names its source system, destination system, data class and the trigger that moves the data.

Flows to external enterprises and providers

This is the part assessors test most directly, because the measure compares documented flows with flows to external enterprises. Include SaaS platforms, payment processors, analytics tools, managed service providers and support access. Pull the list from contracts, procurement records and outbound network logs, then reconcile the two. A provider that appears in logs but not in the documentation is a gap to close before the next review.

Cross-border and cloud region placement

Document the region or jurisdiction where each data class is stored and processed, including backups, replicas and support access from another country. A flow that stays inside one cloud account can still cross regions through replication or disaster recovery. Ask providers to confirm in writing where data is hosted and where administrators access it, and record those answers beside the flow.

Manual and offline transfers

Email attachments, file shares, USB drives, printed reports and exports pulled into spreadsheets are data flows that teams often treat as ad hoc. Survey the teams that handle sensitive data and ask how they share it, with whom and on which devices. Where a manual channel is needed, document it and tie it to a handling rule in the data management process rather than leaving it out of scope.

Review triggers and version control

Assessors check whether documentation was reviewed within the last 12 months and after significant changes. Define which events trigger an update, such as a new provider, a new region or a new integration, and track each review date and approver. A wiki with page history makes it possible to show what changed and when, which is the evidence an assessor will request.

How an assessor tests Safeguard 3.8 in the CIS Assessment Specification

This table compares what an assessor checks for Safeguard 3.8, the evidence they request and the findings that most often cause a failed measure. Read each row as a test the enterprise must pass before the documentation is considered current and complete.

Test area	What the assessor checks	Evidence requested	Common findings
Documentation exists	A data flow record exists for the enterprise and is not missing or a placeholder.	Current data flow diagrams or tables, with a named owner and the scope they cover.	Diagrams exist only as drafts, or the record covers the network but not the data itself.
Review date within 12 months	The last documented review falls within the past 12 months, as the assessment specification requires for a pass.	Version history or change log showing the review date and reviewer, plus the sign-off record.	Last review dates back more than 12 months, or reviews happened without changing the record.
Coverage of external flows	Documented flows are compared with the flows to external enterprises that the assessor identifies from other evidence.	Inventory of service providers and external recipients matched to documented flows, with direction and data type noted.	Flows to SaaS tools, payroll, analytics or backup providers are absent from the documentation.
Undocumented API integrations	Automated transfers through APIs, webhooks and scheduled jobs are included where they move data outside the enterprise.	Integration inventory, API gateway or configuration exports, and the flow entries that correspond to them.	Integrations added by developers or business teams are not recorded because they were never reviewed.
Link to data management process	Flows reflect the sensitivity levels, handling rules and ownership defined under Safeguard 3.1, a prerequisite for this measure.	Data management process document, cross-referenced to each flow's sensitivity and handling requirement.	Flows show no sensitivity, so the assessor cannot tell whether handling rules were applied.
Link to data inventory	Each flow references data types recorded in the data inventory under Safeguard 3.2, another prerequisite.	Data inventory extract with the data sets that appear in each documented flow.	Flows name systems but not the data they carry, so completeness cannot be checked.
Change triggers	The record is updated after significant enterprise changes, not only at the annual review.	Change tickets or architecture review records that show when flows were updated after a migration or new provider.	Diagrams reflect the architecture at the last annual review, not the systems in production today.

How to document data flows step by step

This sequence turns the data inventory and data management process into a reviewed record of where sensitive data moves, who receives it, and how it is protected in transit. Each step produces an artifact that the next step depends on, so the final approved record can be traced back to its sources.

Start from the data inventory and process
Begin with the data management process from Safeguard 3.1 and the data inventory from Safeguard 3.2, since the CIS assessment specification treats both as prerequisites for measuring Safeguard 3.8. Confirm which data classes are in scope, which sensitivity levels the process defines, and which systems the inventory already records as holding each class. The output is a scoped list of data classes with their owners, which becomes the starting point for every flow you document.
Map sources and destinations per data class
For each data class, record where the data originates and every system, team or location where it is stored, processed or consumed. Use the architecture diagrams and application inventories your team already maintains, and check them against the data inventory so no class is missing. The output is a table or diagram showing source, intermediate and destination systems for each class, with gaps flagged for engineers to confirm.
Add service provider and external flows
Extend each map to show data that leaves the enterprise, including flows to cloud platforms, SaaS tools, payment processors, support vendors and other external enterprises. Pull these from contracts, vendor registers and integration configurations rather than memory, because external flows are the ones assessors check for coverage. The output is a complete list of external recipients per data class, each linked to the flow that sends data to it.
Record transport and protection for each flow
For every flow, document the transfer method, the protocol or channel, the encryption applied in transit and at rest on each hop, and the authentication used by the receiving party. Cross-check these entries with the Control 3 encryption Safeguards that apply to your environment and with the service provider's documented controls. The output is a flow register where each row states how the data moves and how it is protected, with unknowns marked for follow-up.
Assign an owner to each flow
Name one accountable owner for each data flow, usually the business or system owner who approves changes to it, and a technical contact who can answer questions about its configuration. Record both names in the register so reviews have a clear point of contact. The output is an owner field completed for every row, with any orphaned flows escalated to the data management process owner before the record moves forward.
Set the annual and change-triggered review
Define the review cadence in the data management process: at least once a year, and again after significant enterprise changes such as a new provider, a migration or a new integration. Record the last review date on the document itself so the 12-month window the assessment specification uses can be checked directly. The output is a review schedule and change trigger list, linked to the change management process that notifies the data owner when a flow is added or altered.
Approve and publish the data flow record
Have the data management process owner and the flow owners review the register for completeness against the inventory and the external recipient list, then record formal approval with the date and approver. Publish the approved version in a controlled location where changes are versioned and older versions can be retrieved. The output is an approved, dated data flow document that serves as the evidence assessors request when testing Safeguard 3.8.

How the data flow record connects to the data inventory and provider list

The data flow record is only as complete as the inventories it is built from. A data flow record that does not reference the data inventory from Safeguard 3.2 will show where data moves without saying what kind of data is moving, and an assessor cannot tell whether the sensitive records are covered. Each flow should name the data set it carries, the classification label that applies to it, the source and destination systems, and the business owner responsible for that path. Those attributes come from the data inventory and the data management process in Safeguard 3.1, so the two documents should be kept in step. Confirm with your data owners that every sensitive data set in the inventory appears in at least one documented flow, and that every flow points back to an inventory entry.

The service provider inventory maintained under Control 15 is the second source to reconcile against. Every external enterprise that receives, processes or stores data should appear as a destination in the flow record, and every provider flow should trace to a contract and a documented security assessment. Assessors look for the gap between flows that stay inside the enterprise and flows that leave it. Internal flows are often well mapped because they run through systems the team administers, while flows to SaaS tools, payment processors, backup vendors and support engineers are added late or never. Compare the provider list with the destinations in the flow record and investigate any provider with no flow, and any external destination with no provider entry.

Encryption in transit under Safeguard 3.10 is the attribute that turns a flow line into testable evidence. For each flow that crosses a network boundary, record the protocol and the minimum version in use, such as TLS or SSH, and whether the endpoints validate certificates. A flow recorded without its transport protection leaves the reader guessing whether sensitive data crosses an untrusted network in the clear. Where a flow uses a protocol that the team cannot confirm, mark it as an open item rather than assuming compliance. Keeping these fields in one record lets a single review cover the inventory, provider and transport questions together.

Evidence that passes a Safeguard 3.8 audit

Safeguard 3.8 is judged on a documented, current set of data flows that covers flows to external enterprises. The artifacts below connect to each other: the register lists the flows, the diagrams show them, the provider annex explains the external ones, and the change log proves the record stayed current. Keep each one tied to the data management process and the data inventory from Safeguards 3.1 and 3.2.

Versioned data flow diagrams

Diagrams showing where sensitive data originates, where it is processed and stored, and where it leaves the enterprise. Each diagram should carry a version number, an owner and a date, and every edit should be kept in version control so an assessor can see what changed and when. Check that each diagram names the data types it covers, not only the systems. Between audits, review diagrams after any new integration, hosting change or provider onboarding, and retire superseded versions in a way that keeps the history readable.

Flow register with owners and review dates

A register listing each data flow with its source, destination, data classification, business purpose, transfer method and accountable owner. The review date for each row is what the assessment checks against the 12-month limit, so a row without a date counts as a gap. Ask the owner of each flow to confirm it quarterly, and keep the register in the same platform as the diagrams so the two cannot drift apart.

Provider flow annex

A section that lists every data flow to an external enterprise, such as a SaaS tool, processor, cloud region or support vendor, with the provider name, the data sent, the contract reference and the security terms that govern the transfer. This annex is where assessors test coverage of external flows, so compare it against accounts payable, procurement records and the Control 15 provider inventory. Missing providers are the most common reason this evidence fails.

Approval records for each flow

Evidence that a named data owner or security approver reviewed and accepted each documented flow before it went live or after it changed. Approvals can be a ticket, a signed change request or a workflow step in the wiki, but each must show who approved, when, and which version of the diagram they approved. Check that no production flow exists without an approval record, because undocumented flows are exactly what the Safeguard targets.

Change log tied to significant changes

A dated log of enterprise changes that trigger a flow review, such as a merger, a new cloud region, a new data type, or a retired provider. The Safeguard calls for review after significant changes as well as annually, so each entry should link to the flow records it affected and show the review outcome. Keep the log reviewed against change tickets from IT operations to confirm that no significant change skipped the process.

Mapping to the data inventory

A cross reference from every documented flow to the data inventory entries it moves, so each data type in the inventory appears in at least one flow and each flow traces to a known data set. This mapping is what shows the flow documentation rests on the data management process rather than on guesswork. Gaps in either direction, data with no flow or flows with no inventory record, should be logged as findings with owners and due dates.

What documenting data flows costs in money and effort

This table breaks down the work behind Safeguard 3.8 by cost component, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to ask providers for line-item quotes. No fees or durations are given because none are supplied for this Safeguard, so the drivers and questions matter more than the figures.

Cost component	One-time or recurring	What drives it up or down
Discovery and mapping labor	One-time at first build, then recurring during reviews	Number of systems, integrations and business units that move sensitive data; up-to-date Safeguard 3.1 and 3.2 outputs reduce interviews and rework
Tooling or licenses	Recurring if commercial diagramming or GRC software is used	Self-hosted wiki or documentation platforms can remove license spend; confirm the data retention and version history features you need before choosing
Engineering time to verify flows	One-time for initial verification, recurring after significant changes	Use of infrastructure-as-code, API gateways and logging makes flows easier to confirm; undocumented point-to-point integrations increase effort
Provider questionnaire follow-up	Recurring, tied to each service provider and contract cycle	Number of external enterprises receiving data, quality of contract clauses, and whether providers can supply their own flow descriptions
Annual review upkeep	Recurring, at least once every 12 months and after significant enterprise changes	Frequency of system changes, number of owners who must confirm their sections, and whether version history makes diffs quick to review
Auditor sampling and evidence requests	Recurring at each assessment or audit cycle	Number of flows sampled, how quickly evidence can be produced, and whether the coverage comparison with external enterprises is already recorded
Remediation of documentation gaps	One-time per gap, recurring if gaps repeat	Quality of change management linked to the documentation; gaps found late in an assessment cost more to close than gaps found in internal reviews

Open-source wiki tools that hold data flow evidence

XWiki is well suited to data flow records that must show how they changed over time. Its strongest contribution to Safeguard 3.8 is version control: every change to a page is kept, so the record shows what changed, when and by whom. That history answers a question assessors often ask, namely whether the documented flows were reviewed and updated after significant changes, and it does so without relying on someone's memory or a shared document folder.

Full change history: Each edit is retained with its author and timestamp, which gives a traceable record of each annual review.
Version comparison: Reviewers can compare any two versions of a data flow page to see exactly which provider, endpoint or data type was added or removed.
Rollback: A page can be restored to an earlier version, which helps when an unreviewed change must be reversed.
Review evidence: Pages can be used to record the reviewer and date of each review, alongside the version that was reviewed.
Self-hosted deployment: Hosting the wiki inside the organization's own infrastructure keeps the history under its control.

Before relying on XWiki history as evidence, confirm with your assessor how they want review dates and approvals recorded, and confirm that backups of the wiki database preserve the full version history.

Common gaps that fail Safeguard 3.8 and how to close them

Assessors measure Safeguard 3.8 against two things: whether a current data flow record exists and whether it covers flows to external enterprises. The gaps below are the ones that most often leave an otherwise mature program with a failing result. Each one has a specific closing action the organization can complete and evidence before the assessment.

Diagrams last reviewed over 12 months ago

The Assessment Specification scores Safeguard 3.8 as failing when data flow documentation was last reviewed more than 12 months ago. Many teams produce a diagram during a project and never revisit it, so the review date silently expires. Check the review date on every flow record, not only on the overall document. Set a recurring review tied to the annual data management process review, and record who reviewed each flow and when. A review date without a reviewer or a changed flow is weak evidence.

SaaS and API flows missing

Flows to software-as-a-service tools, webhooks and third-party APIs are the most common omission, because they are created by product teams or individual staff rather than by infrastructure changes. The coverage metric compares documented flows with flows to external enterprises, so each missing SaaS connection lowers the result. Start from the sanctioned application list, then review OAuth grants, API keys, integration platforms and outbound egress logs to find connections nobody documented. Confirm each one against the data inventory from Safeguard 3.2.

Provider flows not tied to contracts

A flow to a service provider is only defensible when the documented data type, destination and purpose match what the contract and data processing terms allow. Teams often record that a vendor receives customer data but cannot show which contract governs it or which data categories the contract covers. For each external flow, record the contract or data processing agreement reference, the data categories transferred and the provider's location. Gaps found here usually also point to Control 15 service provider management work.

No owner for each flow

A flow without a named owner has no one accountable for approving changes, confirming the data still needs to move, or responding when the provider changes. Ownership usually sits with the business or product team that operates the integration, with the security or data governance function approving entries that involve sensitive data. Assign one owner per flow and record that owner in the documentation platform. Ownerless flows are the first to be left stale in the next review cycle.

Flows not updated after cloud migrations

Cloud moves, region changes, managed database adoption and container platform rollouts change where data travels, often without anyone editing the original network or application diagrams. The Safeguard requires documentation to reflect significant enterprise changes as well as the annual review. Add a required data flow check to change management for migrations, new regions and new managed services, and compare the documented flows with current cloud configuration and network paths before sign-off.

No version history for flow records

When flow documentation is overwritten in place, an assessor cannot see what changed, when, or who approved it, and the organization cannot show that its review actually altered anything. Keep flow records in a platform that stores version history and allows comparison between versions, and export the change log at review time as evidence. This also makes it possible to show what a flow looked like at a past date if an incident or audit needs it.

Questions buyers ask about documenting data flows

How much effort does documenting data flows take?

The effort depends on how many systems move sensitive data, how many external enterprises receive it, and whether a data inventory already exists to start from. Most of the work is discovery: tracing where data originates, which systems process it, which providers receive it, and how it travels between them. Documentation itself is comparatively small once the mapping is agreed. Costs have two parts. Internal staff time from data owners, application owners and network engineers is usually the largest share. External help, if you buy it, is paid for the discovery workshops, the diagrams and the review process. Ask any provider to price discovery, documentation and the annual review as separate line items so you can see what recurs. Safeguard 3.8 is an IG2 and IG3 Safeguard, so it sits after the data management process (Safeguard 3.1) and the data inventory (Safeguard 3.2) in practice.

Can a small internal team document data flows on its own?

Yes, a team can do it alone if it has the access, the time and someone who understands both the data and the network. The work needs input from people who own applications, integrations and vendor relationships, not only from security staff. A common approach is to start with the systems that hold the most sensitive data, map their inbound and outbound paths, then extend the map outward. Teams often struggle with shadow integrations, file transfers set up by business units and SaaS connections added without a central record. If your team lacks capacity or the required skills in data architecture, an implementation partner can run the discovery sessions and prepare the diagrams and documents, while you keep ownership of the content and its approval. Confirm with any partner exactly which artifacts they deliver and who signs off on them.

How long does a first data flow mapping take?

The duration of a first mapping depends on the scale and condition of your environment, not on a fixed formula. The main drivers are the number of applications and data stores in scope, how well existing architecture diagrams and interface catalogs match reality, how many external enterprises receive data, and how quickly data owners can confirm the flows. Organizations with a current data inventory and clear integration records usually move faster than those reconstructing flows from network traffic and interviews. Ask for a written scope and a timeline before work starts. Fixed-scope engagements agree deliverables and dates in writing, which lets you compare proposals on the same basis. Also confirm what happens when discovery finds flows nobody expected, since that often extends the first pass.

Will an auditor check data flows to service providers?

Yes. The CIS Controls Assessment Specification scores Safeguard 3.8 against its coverage metric, which compares documented data flows with data flows to external enterprises. An assessor will therefore look for the provider paths specifically, not only internal flows. Expect questions such as which providers receive sensitive data, what data they receive, how the transfer is protected, and whether the documentation matches the provider inventory maintained under Control 15. Gaps usually appear where a provider was onboarded through a business unit, an API integration was added without a record, or a backup or analytics service receives a copy of data. Confirm with your assessor which framework and version they will test against, because the CIS mapping to ISO/IEC 27001:2022, SOC 2 and PCI DSS links Safeguard 3.8 to different requirements in each.

Is a wiki enough to document data flows?

A wiki can hold the documentation, but it does not create the evidence on its own. What assessors need is a current, approved record of data flows that shows who reviewed it and when. Wiki platforms with version control help here. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack assigns user abilities through roles and lets permissions be overridden per role at the shelf, book, chapter or page level, which helps restrict edits to the data owners who approve flows. Diagrams and data inventories often live elsewhere, so decide which artifact is authoritative and link the rest to it. Confirm that your chosen platform supports the approval workflow and export format your assessor expects.

Is one data flow review each year enough?

Safeguard 3.8 requires review at least once a year, and the CIS Controls Assessment Specification fails the Safeguard when the last review is more than 12 months old. The annual review is a minimum, not a sufficient control on its own. The Safeguard also calls for review after significant enterprise changes, such as a new provider, a new data store, an acquisition or a major system migration. Build a trigger into change management so architecture changes prompt a flow update, and keep a dated record of each review with the approver's name. The recurring cost of this work is the review cycle plus the change-triggered updates, so ask any partner to price both. Retainers are available for ongoing support if you want a provider to maintain the documentation between assessments.

How DeployOpen maps data flows and prepares evidence for Safeguard 3.8

DeployOpen helps organizations map how data moves, including flows to service providers, and prepares the documentation and evidence that Safeguard 3.8 asks for. The organization owns its data flows and its review decisions, while DeployOpen builds the self-hosted systems and records that hold the evidence.

How we scope

Engagements are fixed-scope, with the systems, data sets and external recipients covered agreed in writing before work starts.
The written scope names the data management process and data inventory inputs that the flow documentation will be grounded in.
We confirm which external enterprises receive data, so the coverage check against those recipients is defined up front.

How we build

We set up a self-hosted documentation space where each data flow has an owner, source, destination and data classification.
Flow diagrams and tables are linked to the data inventory entries they describe, so changes can be traced to specific records.
Version history and role-based permissions are configured so reviews, edits and approvals are attributable to named people.

How we hand over

You receive the documented data flows, review records, role configuration and the procedure for the annual review.
We document how new service providers and significant system changes trigger an update to the flow documentation.
Evidence is organized so your internal team or an independent assessor can check coverage against external recipients.

How we support

Ongoing support, upgrades and periodic reviews of the flow documentation are available as a retainer.
Retainer work can add flows for new service providers and keep the review cycle on schedule after handover.
Your organization decides how the annual review is performed and approved, and confirms the documentation meets its own requirements.