GovKM Proposed Standards and Guidance

Enforce Authorized Access Across Retrieval Paths

Protect information and metadata across repositories, indexes, caches and derived answers, and verify grants and revocations.

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: R08.1, R08.2, R08.3, R08.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

Protect information and metadata across repositories, indexes, caches and derived answers, and verify grants and revocations.

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

Security and privacy officials, source owners and system administrators within approved authority.

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

R08.1 Protect information and derived access paths

Suggested approach: Apply approved security and privacy controls across source repositories and derived routes, including catalogs, search indexes, caches and summaries. Determine who may see content and descriptive metadata. Identify where permissions are evaluated and where copies persist. Public guidance does not prescribe actual security configurations; use authorized organizational procedures.

Riverton example: A Riverton staffing summary must not reveal protected case details through its title, snippets or an AI answer. HR approves any project-level attestation separately.

Evidence and completion check: Retain the approved access model and review decisions. Examine representative routes for protected content and metadata using approved non-sensitive examples.

R08.2 Verify grants and revocation

Suggested approach: Test allowed access, denied access, grants, revocations and cross-boundary behavior for representative roles and actual retrieval paths. Include the delay or limitation between a source permission change and its enforcement elsewhere. Establish acceptable conditions through the relevant security process; do not assume immediate propagation.

Riverton example: A departing Riverton coordinator loses access. The test checks the source, search view and retained derived results that remain within the declared system scope.

Evidence and completion check: Keep role, route, time, expected result and observed result for each check. A failed revocation path remains a gap until corrected and retested, with appropriate interim restrictions.

R08.3 Protect integrity and availability

Suggested approach: Protect information integrity and availability using the organization’s selected controls and recovery arrangements. Retain access and audit evidence for justified periods, with appropriate protection and minimization. Coordinate logging duties with business recordkeeping rather than assuming one log serves every purpose.

Riverton example: Riverton’s current briefing can be restored through an approved recovery process, while the records repository protects required approval evidence. Recovery preserves the necessary access restrictions.

Evidence and completion check: Inspect selected controls and safe recovery results. State tested scope and recovery limitations; retain supporting audit evidence according to applicable schedules and privacy rules.

R08.4 Prevent unauthorized retrieval

Suggested approach: Ensure service accounts and retrieval integrations cannot expose information beyond the requesting user’s approved access. Evaluate derived responses as well as source access. Separate information preparation from required privacy, security and accessibility reviews. If a system cannot enforce a material boundary, restrict the dependent use until an authorized resolution exists.

Riverton example: The assistant may state that staffing evidence is unavailable to the user. It cannot use an unrestricted connector account to disclose protected HR information or disguise it in a paraphrase.

Evidence and completion check: Demonstrate permitted and prohibited questions across representative roles. Examine citations, snippets and derived outputs, and retain separate review decisions and unresolved limitations.

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
R08.1	Retain the approved access model and review decisions. Examine representative routes for protected content and metadata using approved non-sensitive examples.
R08.2	Keep role, route, time, expected result and observed result for each check. A failed revocation path remains a gap until corrected and retested, with appropriate interim restrictions.
R08.3	Inspect selected controls and safe recovery results. State tested scope and recovery limitations; retain supporting audit evidence according to applicable schedules and privacy rules.
R08.4	Demonstrate permitted and prohibited questions across representative roles. Examine citations, snippets and derived outputs, and retain separate review decisions and unresolved limitations.

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

Testing only successful access; ignoring derived copies; allowing a service account to disclose beyond the requesting user’s permission.

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.

R08.1 — Protect information and derived access paths

44 U.S.C. 3554 — Information security responsibilities
Issuing body: U.S. Congress; Office of the Law Revision Counsel. Pinpoint: 3554(a)–(b). Relevance: Agency security duties.
Classification: Statute — mandatory when applicable. Applicability: Covered Federal information and systems, including systems operated on an agency’s behalf; national security provisions differ.
5 U.S.C. 552a — Privacy Act
Issuing body: U.S. Congress; Office of the Law Revision Counsel. Pinpoint: (b), (e)(10). Relevance: Disclosure and 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.
32 CFR Part 2002 — Controlled Unclassified Information
Issuing body: National Archives and Records Administration. Pinpoint: 2002.14, 2002.16. Relevance: CUI protection.
Classification: Regulation — mandatory when applicable. Applicability: Executive Branch CUI; nonfederal duties require applicable law, agreement or contract.
NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AC-3, AC-4, AC-6. Relevance: Access 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.
NIST SP 800-171 Revision 3 — Nonfederal CUI protection
Issuing body: National Institute of Standards and Technology. Pinpoint: applicable contract-selected requirements. Relevance: Nonfederal CUI.
Classification: Government technical guidance — conditional on selection or adoption. Applicability: Nonfederal systems handling CUI under applicable agreements or contracts. The incorporated edition governs; a newer NIST publication does not automatically amend a contract.
FAR 52.204-21 — Covered contractor system safeguards
Issuing body: Federal Acquisition Regulatory Council. Pinpoint: 52.204-21(b)(1). Relevance: Contractor safeguards.
Classification: Contract clause — mandatory when applicable and incorporated. Applicability: Covered contractor information systems handling Federal contract information, with clause definitions and flowdown conditions.

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.

R08.2 — Verify grants and revocation

NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AC-2, AC-3, PS-4, PS-5. Relevance: Access lifecycle.
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.
NIST SP 800-53A Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: applicable assessment procedures. Relevance: Test methods.
Classification: Government technical guidance — conditional on selection or adoption. Applicability: Security/privacy control assessment; broader application is an adaptation.
FIPS 200 — Minimum security requirements
Issuing body: National Institute of Standards and Technology. Pinpoint: access control and assessment areas. Relevance: Federal security minimums.
Classification: Federal standard — mandatory within scope. Applicability: Covered Federal information and non-national-security information systems.
FAR 52.204-21 — Covered contractor system safeguards
Issuing body: Federal Acquisition Regulatory Council. Pinpoint: 52.204-21(b)(1)(i)–(vi). Relevance: Authorized contractor access.
Classification: Contract clause — mandatory when applicable and incorporated. Applicability: Covered contractor information systems handling Federal contract information, with clause definitions and flowdown conditions.

GovKM recommendation boundary: Specific test roles and paths are selected for the implementation; these sources prescribe no universal connector test suite.

R08.3 — Protect integrity and availability

FIPS 199 — Security categorization
Issuing body: National Institute of Standards and Technology. Pinpoint: security categorization. Relevance: Impact assessment.
Classification: Federal standard — mandatory within scope. Applicability: Covered Federal information and non-national-security information systems.
FIPS 200 — Minimum security requirements
Issuing body: National Institute of Standards and Technology. Pinpoint: security requirement areas. Relevance: Control selection.
Classification: Federal standard — mandatory within scope. Applicability: Covered Federal information and non-national-security information systems.
NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AU-9, AU-11, CP-9, SI-7. Relevance: Protection and retention.
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: Agency Logging Plan. Relevance: Cyber log planning.
Classification: Federal policy — mandatory provisions within stated scope. Applicability: Covered agency systems; national security and specified defense/intelligence systems excluded.

R08.4 — Prevent unauthorized retrieval

NIST SP 800-53 Revision 5 with Release 5.2.0
Issuing body: National Institute of Standards and Technology. Pinpoint: AC-3, AC-6, RA-8. Relevance: Access and privacy.
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: (b), (e)(10). Relevance: Disclosure 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.
Section 508 Revised ICT Standards
Issuing body: U.S. Access Board. Pinpoint: E203–E206 as applicable. Relevance: Accessible ICT.
Classification: Regulation — mandatory when applicable. Applicability: Federal ICT within 29 U.S.C. 794d and 36 CFR Part 1194; apply E202 exceptions and E205 scoping.
E-Government Act of 2002 Section 208
Issuing body: U.S. Congress; Government Publishing Office. Pinpoint: section 208(b). Relevance: Privacy assessment triggers.
Classification: Statute — mandatory when applicable. Applicability: Covered Federal IT involving identifiable information and covered electronic information collections, with statutory exceptions.

GovKM recommendation boundary: An information-readiness assessment does not complete privacy, accessibility or security authorization reviews.

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.

A newer NIST SP 800-171 edition does not automatically amend a contract. The applicable acquisition instrument and incorporated edition govern the nonfederal system’s obligations.

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.