Getting Answers Out

A different problem than delivery

If you took Secure Software Delivery for Federal Environments, its Module 5 covered moving software into a controlled environment: packaging, a transfer lifecycle where tampering is structural rather than trusted, and deployment where nobody can log in to fix it. Its rule is that the artifact arrives intact and provably unmodified.

This is the other direction and a different artifact. You are not moving code in; you are moving derived results out — a number, a ranked list, a chart in a deck. Three things change:

• The artifact is small and easy to move. Nobody smuggles a container image out in a screenshot. Everybody can do that with a number.
• The control point is classification, not integrity. Whether the result may leave, not whether it arrived unaltered.
• The people doing it are not engineers. Software delivery is performed by teams who know a transfer process exists. Egress is performed by an analyst with a deadline.

That third difference is why this lesson exists. The control that works for software delivery — a documented process engineers follow — does not survive contact with someone who needs one figure for a 4pm meeting.

Prompt first: prepare the release, do not approve it

I need to release a monthly reliability figure outside our secure
boundary, into a board deck.

Help me prepare the release request:
- state the output's own classification and grain, separately from
  the classification of its inputs
- identify whether the grain raises a small-cell concern, with the
  query that counts groups below thresholds of 5, 10, and 25
- list what a release record should capture

Do not tell me whether the release is permitted, and do not draft
anything that assumes approval. Produce what I take to the person
who authorizes it.

Same boundary as Lesson 2.4, for the same reason: an agent asked whether a release is allowed will produce a confident general-purpose answer with no knowledge of your regulator, your contracts, or your classification scheme. It prepares the request. Someone with authority decides.

Classify the output, not the inputs

The rule from Lesson 2.4, applied at the exit rather than the join: what governs egress is the classification of the result.

An aggregate over restricted data is frequently less sensitive than its inputs — that is much of the point of aggregation. Meridian’s fleet-wide reliability percentage derives from customer-linked meter data and is publishable; it appears in the annual report. The same pipeline at segment grain, showing which twelve-household segments lose power most often, is not.

Two errors, and organizations tend to make both at once:

• Inheriting upward — treating every derivative of restricted data as restricted. Produces a boundary nobody can get anything out of, which produces the screenshot.
• Assuming downward — treating aggregation as automatically declassifying. Produces the small-cell publication.

Neither is a rule you apply alone. What you can do alone is know which question you are in, and route it.

Approved channels, and why they must be usable

An approved channel does two things: it applies the check, and it leaves a record of what left, when, and by whose authority.

Typical shapes: a reporting gateway that publishes to a controlled BI surface; a review-and-release step for files; a defined export path with logging. Which one you have is an organizational fact, not a technical one — find out before you need it.

What leaving should record

Whatever the channel, these should exist afterward:

• What left — the data product, its period, its definition_version
• At what grain — the field that decides most sensitivity questions
• Who released it and under what authority
• When, and to what destination

If your channel does not capture these, capturing them yourself in the run record from Lesson 4.4 is a reasonable interim. The eight-month-later question applies to egress as much as to computation: who released this, and were they entitled to?

Key takeaway

Egress of derived results is a different problem from delivering software into a controlled environment: the artifact is trivially movable, the control point is classification rather than integrity, and the person doing it has a deadline rather than a process. Classify the output at its grain — inheriting sensitivity upward makes the boundary unusable, and assuming aggregation declassifies produces the small-cell publication. Use a channel that both checks and records, and treat an approved channel too slow to serve a real meeting as a finding to escalate rather than a rule to work around. Module 6 covers what you owe the product after it is in service.

LEADERSHIP DECISION   fund at least one egress channel fast enough to
                      serve a real deadline; an unusable approved path
                      is what creates the unapproved one
PRACTITIONER ACTION   classify the output at its grain, not its inputs;
                      route small-cell questions; release only through a
                      channel that records what left
SUCCESS MEASURE       every external release traceable to a record naming
                      product, period, grain, and releaser; zero figures
                      leaving by screenshot because the queue was too slow