Keep Meaning and Controls Intact Across Systems

R07.1 Document cross-system exchanges

Suggested approach: Document the information that must survive each participating exchange: identity and version, meaning, dates, approvals, references, access restrictions and lifecycle context where relevant. Map existing fields and identify which system enforces each control. An export specification should describe business meaning as well as file structure.

Riverton example: Riverton’s project view references inspection and IT sources. The mapping explains which dates are assessment dates and which office owns approval, rather than treating similarly named fields as interchangeable.

Evidence and completion check: Retain the mapping and owner approval. Walk through one exchange and explain how an authorized recipient interprets every material field and control.

R07.2 Provide usable export or exchange

Suggested approach: Provide a documented, usable way to exchange or export necessary information and context. Prefer documented open formats where suitable, while meeting preservation and security needs. Check that the route is actually available under the organization’s configuration and permissions. A flat file may be adequate for a small register but inadequate for complex records.

Riverton example: Riverton can export the briefing’s reference list and retrieve the required source revisions through controlled routes. It does not assume a PDF export preserves all original formulas or history.

Evidence and completion check: Demonstrate the exchange with representative approved material. Retain format and access instructions, dependencies and a description of information that the route cannot carry.

R07.3 Verify exchanges and migrations

Suggested approach: Test representative exchanges or migrations against expected business outcomes agreed in advance. Include versions, attachments, dates, references, permissions and lifecycle requirements that matter to the destination use. Reconcile the transferred population and investigate omissions. A successful file transfer is only one part of acceptance.

Riverton example: Riverton moves an approved test inspection file and checks that the correct revision remains locatable, the reference works and an unauthorized user remains denied access.

Evidence and completion check: Keep the test population, expected outcomes, source-to-target observations, exceptions and acceptance decision. Include negative access checks without using real protected personnel data.

R07.4 Identify exchange losses

Suggested approach: Record unsupported fields, degraded content and control losses in an exchange exception record. Identify the dependent uses affected, assign remediation and obtain responsible acceptance where permitted. Do not claim a requirement is satisfied merely because the organization accepts a risk. Keep the existing source authoritative when appropriate.

Riverton example: An export omits Riverton approval evidence. Staff retain the source and limit the receiving view until the approval reference is available; they do not present the export alone as an approved report.

Evidence and completion check: Show one exchange limitation and its treatment. Verify a correction before dependent use, or document that the affected use remains restricted and the requirement remains not demonstrated.

Evidence and completion checks

Agree the population, expected results and acceptance conditions before assessing. Record the date, assessor, evidence reference, observed result and limitation. Use approved safe examples for access, malicious-content or lifecycle tests. Documented policy and observed operating behavior are both relevant; one does not automatically prove the other.

On smaller screens, scroll the table horizontally to view every column.

Record a gap where the required outcome is not demonstrated. Assign an owner and review date, then verify any correction. Completion of this page alone does not demonstrate conformance with all ten domains, certify legal compliance, approve an AI deployment or authorize autonomous actions.

Government Authority and References

U.S. federal reference review: November 9, 2026. These are GovKM mappings of relevance, not government endorsement or a legal compliance determination. Statutes and regulations are mandatory only within their scope; federal policy applies to covered agencies and uses; technical guidance and voluntary resources require the stated selection, adoption or contractual basis. Private and nonfederal organizations must identify their own governing requirements.

The eCFR is authoritative but unofficial. Retrieved Title 36 pages displayed currency through November 5, 2026. Source retrieval does not establish exhaustive legal currency or clause-level implementation compliance. Check current agency supplements, deviations, court orders, schedules, contracts and later amendments. Add the organization’s actual instruments and the qualified official’s applicability determination.

Federal AI-use, high-impact AI, AI-acquisition and covered LLM procurement requirements have distinct scopes and exceptions. Information preparation does not substitute for any applicable AI-use risk acceptance, information-system authorization, procurement or legal decision.

This section gives relevant official references for each covered checklist item and is not an exhaustive list of every possible obligation. The actual agency, program, records, data, system and contract determine additional duties. The EICARS organization of these tasks, suggested registers and completion checks remain GovKM recommendations unless independently required or adopted.