Federated control evidence proves coverage by connecting process documentation and live cloud facts to the same control model. The evidence can stay in authoritative systems, but its source, scope, capture time, owner, validity, and review state must be visible in one assurance graph.
This closes the gap between what a policy says should happen and what the environment shows actually happened. A GRC lead can inspect the procedure and approval trail. A security engineer can inspect the cloud resource, configuration history, and activity. Both follow the same control relationship.
Why Single-Source Evidence Is Not Enough
Most controls cross system boundaries. A change-management control may involve a policy, modeled procedure, pull request, approval, deployment event, cloud configuration change, and exception ticket. No single source contains the complete story.
- Documents show intended behavior but not current technical state.
- Cloud scans show resources and configurations but not the approved procedure or human decisions.
- Tickets show work records but not whether the environment matches the control.
- Screenshots lose source identity, population, history, and machine-verifiable context.
- Dashboard statuses hide the evidence and reasoning behind the conclusion.
Federation preserves each system’s authority while connecting the records required for assurance.
What “Federated” Means for Audit Evidence
Federated evidence is a relationship model over distributed sources, not a larger attachment folder.
| Evidence field | What it proves |
|---|---|
| Source system and object ID | Where the evidence came from |
| Source type | Procedure, approval, event, configuration, ticket, or attestation |
| Collection method | API, event stream, query, export, upload, or reference |
| Capture time and period | When the fact was observed and which period it supports |
| Scope | Accounts, resources, services, teams, locations, and populations covered |
| Integrity metadata | Hash, version, immutable event ID, or retained original |
| Control mappings | Which control activities and requirements it supports |
| Owner and reviewer | Who is responsible and who reached the conclusion |
| Freshness rule | When it expires or which event invalidates it |
| Exception state | What is missing, failing, accepted, or under remediation |
A connector does not make evidence trustworthy. Trust comes from provenance, correct scope, and a defensible mapping to the control activity.
The Assurance Graph: From Requirement to Runtime Fact
An assurance graph makes control coverage inspectable. Its core path is:
- A framework requirement maps to a risk.
- The risk maps to one or more controls.
- Each control maps to an owner, frequency, population, and procedure.
- Procedure steps map to people, systems, and decisions.
- Systems produce evidence from documents, tickets, identity services, repositories, and cloud resources.
- Evidence maps to the relevant control activity and period.
- A reviewer records a conclusion, sample, exception, or follow-up.
- Findings map to remediation work and closure evidence.
Missing edges become visible. A control with cloud evidence but no operating procedure has a process-coverage gap. A procedure with no runtime evidence has an implementation gap. Evidence with no period or scope has a provenance gap.
Process Evidence Proves How the Control Operates
Process evidence covers the human and organizational parts of the control: the approved procedure, responsibilities, decision rules, handoffs, reviews, and exception paths.
Creately Process is the operating-model layer. Teams model and govern workflows from accessible process maps through formal BPMN. Each procedure step becomes a testable claim rather than a paragraph buried in an SOP.
A quarterly access review may claim that the identity team exports every in-scope account, managers review standard access, system owners review privileged roles, security tracks removals, and an independent reviewer verifies completion. Those claims define evidence needed from the identity provider, HR system, review record, ticketing system, and sign-off. The SOC 2 user access review process provides a concrete reference.
Cloud Evidence Proves Current Technical State
Cloud evidence shows configurations, resource relationships, compliance-check results, and activity for in-scope resources. It must be time-bound and resource-specific.
AWS Config records configuration changes and relationships, provides configuration history, and supports rules that evaluate compliance. AWS also states that it delivers a configuration history file for each recorded resource type. See AWS Config concepts and getting started with AWS Config.
Creately Blueprint is the live-environment layer. It scans and visualizes cloud architecture so platform and cloud infrastructure engineers have an always-current, auditable view. A security group, workload, identity, network path, and account boundary can be examined as one architecture rather than isolated evidence rows.
Cloud state still needs interpretation. A compliant configuration alone does not prove that a change was authorized, reviewed, and deployed through the approved process.
Joining Process and Cloud Evidence
Join evidence at the level of the control claim. Do not rely on matching filenames or placing artifacts in one folder.
Consider this production-change claim: “Every infrastructure change is reviewed, approved, deployed through the controlled pipeline, and verified in the production account.”
| Control claim | Process-side proof | Cloud-side proof |
|---|---|---|
| Change was requested | Ticket with scope and risk | Target resource and account IDs |
| Change was reviewed | Pull-request approval | Repository and pipeline identity tied to deployment |
| Approved path was used | Procedure step and deployment record | Cloud event with actor and time |
| Production matches intent | Approved architecture or configuration | Post-deployment state and resource relationships |
| Exceptions were handled | Decision and compensating action | Proof the risky state was removed or constrained |
The relationship between ticket, code change, deployment, and cloud resource is the proof. Disconnected attachments force the reviewer to guess whether they describe the same event.
How to Prove Coverage Without Hiding Gaps
Calculate coverage from required relationships and evidence states, not attachment counts.
- Requirement coverage: applicable requirements map to an approved control.
- Procedure coverage: the control has a current, executable procedure.
- System coverage: every in-scope source and population is represented.
- Time coverage: evidence spans the required period and frequency.
- Evidence coverage: every control claim has relevant proof.
- Review coverage: a qualified reviewer recorded a conclusion.
- Exception coverage: deviations have owners, decisions, and remediation status.
Keep missing, stale, out-of-scope, inconclusive, rejected, and excepted evidence distinct. AWS Audit Manager makes a similar distinction: evidence from sources without automatic compliance evaluation can be inconclusive, which requires manual evaluation rather than an automatic failure. See AWS evidence collection.
Evidence Freshness Must Respond to Change
A fixed expiration date is useful but insufficient. Evidence can become stale the moment its scope or underlying configuration changes.
- Recollect quarterly evidence on the control calendar.
- Invalidate an architecture snapshot after an in-scope resource change.
- Reopen policy mapping when the procedure version changes.
- Recheck ownership when an employee, contractor, or system owner changes.
- Reassess the population when a new account, service, or acquisition enters scope.
- Preserve old evidence for history while marking it superseded.
NIST SP 800-137 frames continuous monitoring around ongoing awareness of security, vulnerabilities, and threats to support risk decisions. Assurance evidence should respond to environmental change rather than wait for the next audit project. See NIST SP 800-137.
A Practical Federated-Evidence Workflow
- Define the control claim. State the owner, scope, frequency, and expected outcome.
- Model the procedure. Use Creately Process to document steps, decisions, responsibilities, systems, and exceptions.
- Identify authoritative sources. Map each claim to its document, ticket, identity, repository, or cloud system.
- Connect the live environment. Use Creately Blueprint to scan in-scope cloud architecture and resource relationships.
- Establish evidence rules. Define source IDs, metadata, scope, validity, integrity, and invalidation events.
- Build the assurance graph. Use Creately Compass to join requirements, controls, workflows, cloud facts, owners, and reviews.
- Evaluate gaps. Check required relationships, assign remediation, and record reviewer conclusions.
- Export the readiness record. Preserve mappings, provenance, period, review state, and exceptions.
Where Creately Compass, Process, and Blueprint Fit
| Product | Primary role | Evidence contribution |
|---|---|---|
| Creately Process | Model and govern workflows | Procedures, responsibilities, decisions, handoffs, and exceptions |
| Creately Blueprint | Scan and visualize live cloud architecture | Current resources, configurations, relationships, and scope context |
| Creately Compass | Connect and evaluate assurance | Requirements, controls, evidence mappings, coverage, reviews, findings, and exports |
Compass complements Vanta and Drata; it does not replace them. A team can retain its compliance-automation hub while using Compass to structure process and SOP evidence, then join that context to live cloud facts.
The SOC 2 readiness evidence-pack guide shows how this evidence set becomes a review-ready audit handoff. The continuous audit-readiness software buyer’s guide provides evaluation criteria for mapping, evidence, scoring, reviews, and exports.
Questions to Test the Design
- Can a reviewer follow a requirement to its control, procedure, system, evidence, and conclusion?
- Does every evidence object retain its authoritative source and stable ID?
- Can one evidence object support several controls without being copied?
- Does a scope or configuration change invalidate affected evidence?
- Can the model distinguish missing, stale, inconclusive, rejected, and excepted proof?
- Are process claims tested against live technical state?
- Can owners see gaps without approving their own evidence?
- Does the exported pack preserve relationships outside the platform?
If the answer depends on a spreadsheet rebuilt before every audit, the evidence is not yet federated.
FAQs About Federated Control Evidence
Is federated evidence the same as automated evidence collection?
Does an assurance graph replace the original evidence?
Can one cloud configuration prove a control?
How does federated evidence reduce audit work?
What is the role of Creately Compass?
