Dependency Mapping · where the boundary meets Zero Trust

One boundary, authorized once. Every application inside it, segmented on what it actually does.

The general support system is the landing zone's authorized core: drawn, categorized, its crossings registered, its common controls inherited by everything inside. Application Dependency Mapping is a separate engagement on its own clock — twelve weeks minimum, sixteen for core applications — and it reads what each application actually does, beside what its owners declared. The handoff to Zero Trust is the map itself, labelled: every endpoint by role, application, environment and location; every validated flow a labelled allow. We define the labels and the first policy set. We do not run the platform; we prepare it to jump-start. Together they make a landing zone that can accelerate each application's authorization. Not by attesting. By answering, from cited evidence, the questions an assessor would otherwise ask each application to answer alone.

Recommended alongside Foundations. Not a requirement of it.

Attestation is not proof. Observation is not permission. Inheritance is not assumed.

The general support system

The boundary, authorized once.

The shared core every application sits inside: directory, logging, key management, endpoint protection, the network and its inspection stack, privileged identity.
Behind the enterprise cloud boundary. In DoD terms the SCCA: the access point, the virtual security stack, the managed services, the credential manager. In a civilian agency, the TIC 3.0 boundary.
Inheritance in tiers: the provider's authorization, the enterprise boundary, the general support system, then the application. Per control, per application, in four states: fully inherited, hybrid, customer-specific, or provider-claimed and unverified.

It is a boundary and a set of common controls. It is not an application's authorization.

The dependency map

What actually talks.

One row per dependency: from, depends on, kind (data · identity · network · service · schedule), declared (yes or no), observed (unobserved · matched · unmatched · conflict), and the registered source the observation rests on.
Twelve weeks of observation from the platform's install is the minimum, sixteen for core applications; application observation happens here, not inside the six weeks. Matched confirms a row. Unmatched keeps it open with an owner and a clock. Conflict blocks. Observed but never declared is a finding.
A declared dependency is the client's account. An observed one is a flow record or a log, cited. The match is explicit: never inferred, never averaged, never painted over.

It reads. It does not grant. A row without a source stays unobserved.

Zero Trust

Validated purpose becomes policy. Nothing else does.

The handoff is the map itself. Every endpoint carries four labels: role, application, environment, location. A validated flow becomes an allow between labels, not between addresses: this role of this application, in this environment, may reach that one.
At the boundary the crossings are the only paths in and out, each with a mechanism, an owner and a clock. Inside, deny by default; allow by exception; exceptions expire.
The labels and the first policy set are defined from the baseline and walked at the table-top before anyone signs. Enforcement is the platform's, run by the day-two team under its change process. We prepare the jump-start; we do not run the platform.

Three pillars: Visibility, Network & Environment, Application & Workload, at the target level your regime asks for.

One boundary. Two applications.

What the record shows at the baseline.

Declared only Observed, matched Conflict, or observed and never declared Crossing on the register A segment inside the authorized boundary

A fictional example, kept from the home page. The lines are the dependency map; the boxes are the boundary, the general support system and the segments. Nothing in it is a client's.

Declared. Observed. Labelled. Policy.

Six rows of the example, read at four moments: the client's account before observation begins, the baseline the Authorizing Official reads, the labels the map assigns each endpoint, and what a named person let become policy. Labels read as application:role, with environment and location shared.

Row	From → depends on	Kind	Declared	Observed at the baseline	Labelled	Policy
A-1	Application A → managed directory	identity	declared	matched · flow records	`accounts:web → gss:directory` · prod · enclave	Allow, inside the segment. Inherits the directory's controls.
A-2	Application A → managed logging	service	declared	matched · via C-2, confirmed	`accounts:web → gss:logging` · prod · enclave	Allow. Observed ports and endpoints replace the placeholders.
A-3	Application A → Database A	data	declared	matched · flow records	`accounts:web → accounts:db` · prod · enclave	Allow, inside the segment.
B-1	Application B → Database A	data	declared	conflict · observed to Database B, not in the catalog	`reporting:app → unlabelled` · no catalog entry, no label	Blocked. No segment for B until a named person resolves which database is true.
C-4	Application B → another domain, batch	data	declared	unmatched · never seen in the window	`reporting:batch → external:other-domain` · declared side only	Row stays open: mechanism not yet decided, owner named, clock running. No allow.
C-5	Message queue → Application B, direct	service	not declared	matched · a crossing not on the register	`external:queue → reporting:app` · labelled at validation, not before	Finding, with an owner and a clock. No allow until purpose is validated and the register carries it.

Three of six rows become labelled allows. Three stay open with a name and a date. That is the record working, not failing.

What each application would otherwise have to produce alone.

An authorization case is built from evidence about a boundary, its connections, its flows, its monitoring and what it inherits. Inside an authorized general support system, with the map beside it, most of that evidence already exists, cited, before the application's own case is opened. Each row names the control it answers and what the answer stands on.

The application alone would produce	The record already holds	Control answered	Standing
Its boundary and the components in it	A segment inside the authorized boundary; components from the catalog, with the gaps observation found	`SC-7 · CM-8`	inherited
Its internal connections	Every inside-the-boundary row, observed and cited	`CA-9`	observed
Its external exchanges	The crossings register: mechanism, owner, clock per crossing; open rows named, not hidden	`CA-3`	observed
Its information-flow policy	Validated purpose as allow; deny by default; exceptions with an expiry	`AC-4 · SC-7(5)`	prepared
Its isolation from its neighbours	The segment itself, and the boundary's macro-segmentation above it	`SC-7(21) · SC-32`	prepared
Its monitoring evidence	Twelve weeks of flow records and logs, cited to registered sources	`SI-4`	observed
Its inheritance claims	Per control, per application, in four states; provider-claimed marked unverified until it is not	`common controls`	mapped
Its segmentation labels and first policy set	Every endpoint labelled on four dimensions from the map; every validated flow a labelled allow, in the form the platform ingests. Defined, not deployed.	`AC-4 · SC-7(21)`	prepared
Its readiness answers	Three of the authorization print's checks answered from what the system does: components and flows, evidence observed, inheritance mapped	`the print`	from evidence

Control identifiers are NIST SP 800-53 Rev. 5 and are printed as identifiers only, which keeps the row honest and the page short.

Not an attestation. Every row is a cited observation or an inherited control with its provenance. The record refuses rather than invents, and what it still lacks, it prints.

What stays the application's own

Its data and its categorization.
Its identity design and its roles.
Its code, its patching, its customer-specific controls.
Every exception it asks for, and the expiry it accepts.
Its Authorizing Official's decision.

What it is not

Not an authorization.
Not the platform's operation. We define the labels and the first policy set; the mission's team runs the platform that enforces them.
Not product lock-in. Any source that produces flow records or logs can be registered; none is named here.
Not a requirement of Foundations. Recommended alongside it.

Bring the inventory you have. We will tell you what it does not know.

Who runs the platform on day two, and under which change process, is on Operate. Which Zero Trust target each edition reads against is on Editions.

Start a conversation