GovKM Proposed Standards and Guidance

Preserve the Source and History Behind Information

Distinguish source information from derivatives and preserve attributable evidence of material changes and missing history.

GovKM-proposed public draft. Published for public review. Not externally accredited or endorsed.

View the EICARS framework resource

Document

Return to the EICARS guidance index

EICARS implementation guidance — proposed public draft. Checklist coverage: R03.1, R03.2, R03.3, R03.4. Prepared November 9, 2026. These suggested approaches support the published GovKM-proposed EICARS v0.1 draft; they do not add requirements or grant external accreditation.

Purpose and use

Distinguish source information from derivatives and preserve attributable evidence of material changes and missing history.

Use this guide within a declared organizational scope, with existing repositories and suitable organizational processes. AI is optional. Examples and suggested evidence are implementation aids; the published standard governs a conformance assessment. The Riverton case below is fictional, not an observed deployment or test result.

Responsible roles

Source owners, records officials and platform administrators within their assigned responsibilities.

Assign responsibilities through the organization’s actual instruments. A suggested role in this guide does not itself confer decision authority.

R03.1 Distinguish originals and derived information

Suggested approach: Describe the role of originals, authorized copies, exports, OCR text, reports and other derived information. Keep a usable reference to the source and relevant version when a transformation matters to interpretation. Document material conversion limitations, such as missing annotations or formulas. A derivative can have its own recordkeeping significance; records staff determine the treatment.

Riverton example: The Riverton briefing cites the facilities report rather than treating an extracted paragraph as the complete report. The extraction notes that the signed attachment must be consulted for the inspection’s approval evidence.

Evidence and completion check: Retain the source reference and transformation description. Compare a representative derivative with its source and identify omissions that could change the business interpretation.

R03.2 Retain evidence of material changes

Suggested approach: Use existing version history, workflow records or controlled change logs to retain attributable evidence of material changes. Record actor or system, time and reason where available. Define materiality according to business and legal need. If a reason was never captured, state that limitation; do not manufacture a plausible history.

Riverton example: A Riverton readiness report corrects an inspection finding. The prior revision remains distinguishable, and the correction evidence identifies the responsible office and when the correction was recorded.

Evidence and completion check: Show the prior state, changed state and available attribution. Retain the approved correction evidence and describe gaps. Cybersecurity event logs alone may not explain the business reason for a change.

R03.3 Protect history and source evidence

Suggested approach: Protect necessary source and history records against unauthorized alteration or loss. Apply access, preservation, recovery and retention controls appropriate to their sensitivity and business role. Avoid retaining every log indefinitely: records, security, privacy and legal officials should determine applicable periods and holds.

Riverton example: An ordinary Riverton contributor cannot overwrite the protected approval record. Authorized corrections follow the established process and preserve the evidence needed to understand the change.

Evidence and completion check: Examine access configuration and an approved safe alteration or recovery demonstration. Retain the result, recovery limitations and applicable retention decisions; a backup by itself does not prove a usable history.

R03.4 Expose missing history and uncertainty

Suggested approach: Make missing provenance visible at the time of assessment. State what is supported, what is unknown, who is responsible for review and which uses remain limited. Content comparisons and integrity checks may help detect alteration, but cannot establish who had authority to approve a document.

Riverton example: An old Riverton report has no reliable approval history. Staff can describe its contents while withholding the claim that it was the approved readiness determination.

Evidence and completion check: Keep the dated gap finding and supporting observations. Ask a reviewer to separate verified facts from assumptions and confirm that an unresolved item has not silently been marked complete.

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.

Item	Suggested evidence and demonstration
R03.1	Retain the source reference and transformation description. Compare a representative derivative with its source and identify omissions that could change the business interpretation.
R03.2	Show the prior state, changed state and available attribution. Retain the approved correction evidence and describe gaps. Cybersecurity event logs alone may not explain the business reason for a change.
R03.3	Examine access configuration and an approved safe alteration or recovery demonstration. Retain the result, recovery limitations and applicable retention decisions; a backup by itself does not prove a usable history.
R03.4	Keep the dated gap finding and supporting observations. Ask a reviewer to separate verified facts from assumptions and confirm that an unresolved item has not silently been marked complete.

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.

Common mistakes

Overwriting relevant prior states; inventing missing history; treating a checksum as proof of approval.

Continue the checklist

Use this page with the EICARS standard, the identity guide and the full Riverton scenario. No particular product, model or repository migration is required.

Implementation overview

Suggested operating approach: assign the responsible roles, confirm applicability, implement suitable controls in the existing environment, examine operating evidence and track unresolved gaps. Tailor the methods to scale and risk. Maintain current services during preparation and preserve records, access and legal obligations throughout.

Standards traceability and references

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.

R03.1 — Distinguish originals and derived information

36 CFR 1236.10 — Electronic records controls
Issuing body: National Archives and Records Administration. Pinpoint: 1236.10(b), (e)–(g). Relevance: Record context.
Classification: Regulation — mandatory when applicable. Applicability: Federal agency records within the source’s statutory and regulatory scope. Not a general obligation on private organizations.
NARA Bulletin 2015-04 — Transfer metadata
Issuing body: National Archives and Records Administration. Pinpoint: minimum transfer metadata. Relevance: Transfer description.
Classification: Agency bulletin — requirements within stated transfer scope. Applicability: Transfers of permanent electronic records to NARA.
36 CFR 1222.22, 1222.24, 1222.26 and 1222.28 — Documentation and recordkeeping
Issuing body: National Archives and Records Administration. Pinpoint: 1222.26(a)(2)–(4). Relevance: Related records and copies.
Classification: Regulation — mandatory when applicable. Applicability: Federal agency records within the source’s statutory and regulatory scope. Not a general obligation on private organizations.

GovKM recommendation boundary: The cited sources support the underlying governance outcome. This checklist’s packaging, evidence register and assessment format are GovKM recommendations unless separately adopted.

R03.2 — Retain evidence of material changes

36 CFR 1236.10 — Electronic records controls
Issuing body: National Archives and Records Administration. Pinpoint: 1236.10(c). Relevance: Integrity.
Classification: Regulation — mandatory when applicable. Applicability: Federal agency records within the source’s statutory and regulatory scope. Not a general obligation on private organizations.
NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AU-3, AU-8, CM-3. Relevance: Audit and change controls.
Classification: Government technical guidance — conditional on selection or adoption. Applicability: Selected controls, baselines, tailoring and applicable policy or contracts determine obligations. Not every catalog control is universally mandatory.
OMB M-26-14 — Agency logging and network visibility
Issuing body: Office of Management and Budget. Pinpoint: Prioritization; Agency Logging Plan. Relevance: Scoped cyber logging.
Classification: Federal policy — mandatory provisions within stated scope. Applicability: Covered agency systems; national security and specified defense/intelligence systems excluded.

GovKM recommendation boundary: Logging scope, retention and attribution depend on business need and applicable requirements; the cybersecurity memorandum does not require logging every business edit.

R03.3 — Protect history and source evidence

44 U.S.C. 3105 — Safeguards
Issuing body: U.S. Congress; Office of the Law Revision Counsel. Pinpoint: 3105. Relevance: Records safeguards.
Classification: Statute — mandatory when applicable. Applicability: Federal agency records within the source’s statutory and regulatory scope. Not a general obligation on private organizations.
NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AU-9, AU-11, SI-7. Relevance: Audit protection.
Classification: Government technical guidance — conditional on selection or adoption. Applicability: Selected controls, baselines, tailoring and applicable policy or contracts determine obligations. Not every catalog control is universally mandatory.
5 U.S.C. 552a — Privacy Act
Issuing body: U.S. Congress; Office of the Law Revision Counsel. Pinpoint: (e)(10). Relevance: Personal-record safeguards.
Classification: Statute — mandatory when applicable. Applicability: Covered agency systems of records and individuals, subject to definitions, exceptions and exemptions; section (m) can cover contractors.
OMB M-26-14 — Agency logging and network visibility
Issuing body: Office of Management and Budget. Pinpoint: Agency Logging Plan. Relevance: Cyber logging obligations.
Classification: Federal policy — mandatory provisions within stated scope. Applicability: Covered agency systems; national security and specified defense/intelligence systems excluded.

R03.4 — Expose missing history and uncertainty

OMB Circular A-123 revised March 10 2026
Issuing body: Office of Management and Budget. Pinpoint: section IV(A), (C). Relevance: Assessment documentation.
Classification: Federal policy — mandatory provisions within stated scope. Applicability: Executive agencies as defined in its Applicability section.
5 U.S.C. 552a — Privacy Act
Issuing body: U.S. Congress; Office of the Law Revision Counsel. Pinpoint: (d), (e)(5). Relevance: Covered record disputes.
Classification: Statute — mandatory when applicable. Applicability: Covered agency systems of records and individuals, subject to definitions, exceptions and exemptions; section (m) can cover contractors.
NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: SI-7. Relevance: Integrity checking.
Classification: Government technical guidance — conditional on selection or adoption. Applicability: Selected controls, baselines, tailoring and applicable policy or contracts determine obligations. Not every catalog control is universally mandatory.

GovKM recommendation boundary: Explicit uncertainty labels and assessment dates are recommended evidence practices. An integrity check does not prove delegated decision authority.

OMB M-26-14 rescinded M-21-31. Its cybersecurity logging scope does not require recording every business edit or retaining every log indefinitely. Use the current CISA logging architecture and applicable implementation instructions for an actual covered system.

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.

Version history

November 9, 2026 — Publication authorized by GovKM. Guidance based on checklist and government authority reference package checked November 5, 2026. References must be periodically revalidated.

November 9, 2026 — Expanded implementation guidance, version 0.1. Replaced the shorter implementation text with the reviewed Riverton examples, task-specific approaches, evidence checks and official authority mappings, with Robert Noyes’s approval. Existing URLs and checklist anchors are preserved. No EICARS requirement or GovKM doctrine is amended.