Federal civilian · Moraph software

FedRAMP ATO Accelerator

Draft your System Security Plan from how your system is actually configured

Book a demonstration Request a technical briefing Factsheet

Overview

What you are buying

The FedRAMP ATO Accelerator reads the configuration of your cloud environment, code repositories and security tools, and drafts control implementation statements, evidence and the System Security Plan from what it finds. Your compliance team reviews and approves every statement before it goes into the package. The package stays tied to the live configuration, so when the system changes you see which controls and documents are affected.

The problem it solves

Preparing for a FedRAMP or agency authorization means describing hundreds of NIST SP 800-53 controls in a System Security Plan, collecting evidence for each, and keeping all of it current through assessment and continuous monitoring. Most teams write these documents by hand in word processors and spreadsheets, interviewing engineers to find out how the system works. The documents drift from the real configuration as soon as they are written, and assessors find gaps between what the plan says and what the system does.

Control statements are written from interviews and memory rather than from the system itself
Evidence is gathered by screenshot and spreadsheet, and goes stale between assessments
Changes to the system are not traced to the controls and documents they affect
POA&M items, scan results and monthly deliverables are tracked in separate files

Who uses it

Software and cloud service providers pursuing FedRAMP authorization
Agency system owners and ISSOs preparing an agency authorization to operate
Compliance and GRC teams who write and maintain the security package
Cloud and platform engineers who are asked to explain how controls are implemented
Independent assessors and agency reviewers who need traceable evidence

Requirements it supports

FedRAMP Authorization Act (44 U.S.C. 3607-3616)Federal Information Security Modernization Act of 2014 (44 U.S.C. 3551 et seq.)NIST SP 800-53 Rev. 5, Security and Privacy ControlsNIST SP 800-37 Rev. 2, Risk Management FrameworkFIPS 199, Standards for Security CategorizationOMB Circular A-130, Managing Information as a Strategic Resource

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

Step 1

Control status

The compliance lead starts from the baseline: each control with its owner, how it was drafted and where it stands.

Control	Title	Owner	Drafted from	Status
AC-2	Account Management	Identity team	Identity provider settings	In review
AU-11	Audit Record Retention	Platform team	Logging configuration	Approved
SC-13	Cryptographic Protection	Platform team	Encryption settings	Drafted
PS-3	Personnel Screening	HR lead	No configuration source	Needs a writer
CM-6	Configuration Settings	Platform team	Infrastructure code	Drift flagged

Step 2
A drafted statement
Each drafted statement shows the configuration it was built from, so the control owner can check it against what they know.
FedRAMP ATO Accelerator · Control AC-2Sample data
AC-2 Account Management · Example Cloud Service (fictional)
Baseline
Moderate
Implementation
Shared: partly inherited
Control owner
Identity team
Drafted
From identity provider settings
Status
Submitted for approval
Evidence cited
- Account inactivity setting: disabled after 90 days
- Group-based role assignment for administrators
- Account creation logged to the central log store
Approve into packageReturn with comments
Each drafted statement shows the configuration it was built from, so the control owner can check it against what they know.
Step 3
Drift detected
When configuration changes, the affected controls are flagged and the change is reviewed rather than discovered at assessment.
FedRAMP ATO Accelerator · Drift DR-0412Sample data
Drift DR-0412 · Log retention setting changed
1. Retention on application logs changed in infrastructure codeAccelerator
2. Controls AU-11 and CM-6 flagged for reviewAccelerator
3. Change confirmed as intended, new value recordedEngineer
4. AU-11 statement updated to the new valueControl owner
5. Updated statement approvedCompliance lead
When configuration changes, the affected controls are flagged and the change is reviewed rather than discovered at assessment.

Step 4

The POA&M

Findings from scans and assessments are tracked as POA&M items with an owner and milestones.

Item	Weakness	Source	Severity	Owner	Status
POAM-118	Outdated TLS library on worker image	Container scan	High	Platform team	Remediation in progress
POAM-117	Missing banner on admin console	Assessment	Low	Identity team	Fix awaiting verification
POAM-112	Unused service account	Configuration check	Moderate	Identity team	Closed
POAM-109	Patch level on bastion host	Infrastructure scan	Moderate	Platform team	Milestone overdue

Step 5
Package version
Approved content is assembled into a package version that the system owner approves before it is shared.
FedRAMP ATO Accelerator · Package v4Sample data
Package version 4 · Example Cloud Service (fictional)
Baseline
Moderate
Controls approved
All in baseline
Changed since v3
14 statements, 2 components
Open POA&M items
6
System owner approval
Pending
Outputs
- System Security Plan (document)
- SSP, POA&M and component definitions (OSCAL)
- Evidence index with dates
Approve versionCompare with v3
Approved content is assembled into a package version that the system owner approves before it is shared.

Step 6

Sharing with the assessor

Assessors get read-only, time-limited access to the version and evidence you choose, and every download is logged.

Reviewer	Organization	Scope	Access ends	Downloads
Assessor A (fictional)	Example Assessment Firm	Package v4 and evidence	End of assessment window	23
Reviewer B (fictional)	Example Agency	Package v4, SSP only	End of review period	3
Assessor C (fictional)	Example Assessment Firm	Package v3	Expired	41

Workflows

The principal workflows

Connect
The Accelerator connects read-only to your cloud accounts, infrastructure-as-code repositories, identity provider and security tools, and builds an inventory of the components inside the authorization boundary.
- Read-only connections set up to cloud accounts, repositories and security tools
- Components discovered and proposed for the boundary
- Compliance lead confirms what is inside and outside the boundary
- Security categorization and FedRAMP baseline recorded
- Inherited controls from the underlying cloud provider identified
Draft
For each control in the baseline, the Accelerator matches configuration settings and tool outputs to the control's requirements and drafts an implementation statement that cites the evidence it used.
- Configuration and tool outputs mapped to controls and parameters
- Implementation statement drafted with the evidence cited
- Controls with no supporting configuration flagged for a person to write
- Control owner reviews, edits and submits the statement
- Compliance lead approves it into the package
Assemble
Approved statements, the boundary inventory and evidence are assembled into the System Security Plan and its attachments, in OSCAL and in document form, for your assessor and authorizing official.
- Package completeness checked against the selected baseline
- SSP and attachments generated from approved content
- OSCAL files produced alongside the documents
- System owner approves the package version
- Package shared with the assessor through scoped read-only access
Monitor
After authorization, the Accelerator keeps checking the configuration. When something changes, it shows which controls, statements and evidence are affected, and tracks scan findings and POA&M items for continuous monitoring.
- Configuration rechecked on the schedule you set
- Changes compared with the approved package
- Affected controls and statements flagged for review
- Scan findings imported and linked to POA&M items
- Monthly continuous monitoring deliverables prepared for review

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Compliance lead

FedRAMP program manager, GRC lead, information system security officer (ISSO)

Runs the authorization effort: assigns controls, approves statements into the package and prepares continuous monitoring deliverables.

Sees

Every control, drafted statement, evidence item and POA&M entry
Package completeness against the selected baseline
Drift alerts and the controls they affect
The audit trail of drafts, edits and approvals

Does

Selects the baseline and records the security categorization
Assigns controls to control owners
Approves or returns implementation statements
Prepares package versions for system owner approval
Assembles monthly continuous monitoring deliverables
Grants scoped access to assessors and agency reviewers

Cannot

Approve a statement they wrote themselves; a second approver is required
Approve a package version for release; that is the system owner's decision
Edit or delete entries in the audit trail

Approvals: Approves control statements written by others; package versions they prepare are approved by the system owner.
Notified about: Statements submitted for approval, controls flagged by drift, POA&M milestones coming due, and assessor access approaching expiry.

Control owner

Security engineer, IT operations lead, privacy officer, HR or physical security lead for non-technical controls

Makes sure the statements for their controls describe what the system actually does, and supplies evidence where it cannot be collected automatically.

Sees

Controls assigned to them, with the drafted statement and the evidence cited
Configuration findings and drift alerts for their controls
Comments and returns from the compliance lead

Does

Reviews, edits and submits drafted statements
Writes statements for controls the Accelerator could not draft
Uploads procedural evidence such as policies and training records
Responds to drift alerts on their controls
Records customer responsibilities and inherited control details

Cannot

Approve their own statements into the package
See controls assigned to others unless the compliance lead grants it
Change the baseline or the boundary

Approvals: Every statement they submit is approved by the compliance lead.
Notified about: Controls assigned to them, statements returned with comments, and drift on their controls.

Engineer

Cloud engineer, platform engineer, DevSecOps engineer, site reliability engineer

Keeps the connections working and resolves the configuration issues, drift and findings that affect the package.

Sees

Connections and their status
Discovered components and configuration findings
Drift alerts and POA&M items assigned to them

Does

Sets up read-only connections to cloud accounts, repositories and tools
Explains configuration to control owners through comments
Remediates findings and records the fix on the POA&M item
Marks intended changes so reviewers know a drift alert was expected

Cannot

Approve statements or package versions
Close a POA&M item without compliance lead review
Change the boundary

Approvals: Fixes they record on POA&M items are verified by the compliance lead before an item is closed.
Notified about: Connection failures, POA&M items assigned to them, and drift alerts on components they own.

System owner

System owner, chief information security officer, product executive accountable for the authorization

Accepts accountability for the boundary and the package and approves what is shared with assessors and the authorizing official.

Sees

Package status, completeness and open gaps
The boundary inventory and inherited controls
Open POA&M items and their milestones
Package versions and the changes between them

Does

Approves the authorization boundary
Approves each package version for release
Accepts or returns risk decisions recorded on POA&M items
Reviews continuous monitoring status

Cannot

Edit control statements directly
Remove entries from the audit trail
Grant authorization; that decision belongs to the authorizing official

Approvals: Approves the boundary, package versions and risk decisions.
Notified about: Package versions waiting for approval, POA&M milestones overdue, and significant changes flagged by drift detection.

Assessor or agency reviewer (read-only)

Third-party assessment organization assessor, agency authorizing official's staff, FedRAMP reviewer

Reviews the package and evidence for an assessment or authorization decision without being able to change anything.

Sees

The package version and evidence within the scope granted
Statement history and approvals
POA&M items and continuous monitoring deliverables shared with them

Does

Reads and searches the package and evidence
Downloads documents and OSCAL files, with each download logged
Leaves review comments where the compliance lead enables them

Cannot

Change, approve or delete anything
See content outside the scope and dates granted
Keep access after it expires

Approvals: Their access is granted by the compliance lead with a scope and an end date.
Notified about: Nothing by default; new package versions shared with them if the compliance lead chooses.

Administrator

Application administrator, IT administrator

Manages users, roles and connections without approving package content.

Sees

Users, roles and teams
Connection settings and their status
The record of permission changes

Does

Adds and removes users, or maps them from single sign-on groups
Assigns roles
Manages connection credentials with the engineer
Runs access review reports

Cannot

Approve statements, package versions or risk decisions
Grant themselves the compliance lead or system owner role without a second approver
Edit the audit trail

Approvals: Role changes that grant approval rights are approved by the system owner.
Notified about: Access reviews coming due and accounts not used for a period your policy sets.

Permissions at a glance

Action	Compliance	Control owner	Engineer	System owner	Assessor	Admin
Set up connections	View only	No access	Full	No access	No access	Full
Confirm the boundary	Full	No access	View only	Approves	View only	No access
Edit control statements	Full	Own work only	No access	No access	No access	No access
Approve control statements	Approves	No access	No access	View only	View only	No access
Upload evidence	Full	Own work only	Own work only	No access	No access	No access
Respond to drift alerts	Full	Own work only	Own work only	View only	No access	No access
Manage POA&M items	Full	Own work only	Own work only	Approves	View only	No access
Approve a package version	No access	No access	No access	Approves	View only	No access
Export SSP and OSCAL files	Full	No access	No access	Full	View only	No access
Grant assessor access	Full	No access	No access	Approves	No access	No access
View audit trail	View only	No access	No access	View only	View only	View only
Manage users and roles	No access	No access	No access	Approves	No access	Full

Full
Own work only
Approves
View only
No access

How access is controlled

Nothing drafted by the Accelerator enters the package without a person's approval, and nobody approves a statement they wrote themselves.
Roles are configured with you during implementation. Control owners can be limited to their own controls, and roles can be renamed or added to match your organization.
Every permission change is recorded in the audit trail with who made it and when, and access review reports list each person's roles for periodic certification.
Staff sign in through your identity provider, and roles can follow its groups. Assessors and agency reviewers get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

Configuration-based drafting

Implementation statements are drafted from the settings the Accelerator reads, and each one cites the configuration and tool outputs it relied on.

Boundary inventory

Components discovered from your cloud accounts and repositories, with a person confirming what sits inside the authorization boundary.

Control baselines

FedRAMP Low, Moderate and High baselines and NIST SP 800-53 Rev. 5 controls, with parameters and customer responsibilities recorded per control.

Inherited and shared controls

Controls inherited from your infrastructure provider recorded with the source, so the plan shows what you implement and what you rely on.

Evidence library

Evidence collected automatically where a connection allows, or uploaded by control owners, dated and linked to the controls it supports.

Drift detection

Changes in configuration compared with the approved package, with the affected controls and statements flagged for review.

Review and approval

Every drafted statement is reviewed by its control owner and approved by the compliance lead; nothing enters the package without a person's approval.

OSCAL output

The SSP and related content produced in NIST's Open Security Controls Assessment Language as well as document form.

POA&M tracking

Weaknesses from scans and assessments tracked as POA&M items with owners, milestones and status.

Continuous monitoring

Scan results imported on your schedule and monthly deliverables assembled for the compliance lead to check and send.

Package versions

Each approved package version kept, with a comparison of what changed between versions and who approved it.

Assessor access

Read-only, time-limited access for assessors and agency reviewers to the package and evidence within the scope you grant.

Integrations

How it connects to your systems

Connects to	How	What flows
Cloud provider accounts	Read-only connections to AWS, Microsoft Azure and Google Cloud accounts to read resource configuration, identity settings, logging and encryption settings.	In: resource inventory and configuration settings.
Infrastructure as code	Terraform and other infrastructure-as-code repositories read from your source control, so statements can cite the code that defines a setting.	In: configuration definitions and commit history.
Identity provider	Your identity provider's settings for multi-factor authentication, session limits and group membership, used as evidence for access control statements.	In: authentication policies and group membership.
Vulnerability scanners	Scan results from the infrastructure, container and web application scanners you already use, imported for continuous monitoring and POA&M tracking.	In: scan findings, severities and dates.
Ticketing systems	POA&M items and drift alerts can create tickets in Jira or ServiceNow, and ticket status is shown on the item.	Out: remediation tickets. In: ticket status.
OSCAL export	SSP, POA&M and component content exported in OSCAL for your assessor, agency or FedRAMP submission.	Out: OSCAL files and document versions.
Single sign-on	Staff sign in through your identity provider (SAML or OpenID Connect).	In: user identity and group membership for role assignment.
Software bill of materials	Component inventories from Moraph's Software Bill of Materials (SBOM) Watchtower or your own SBOM tooling, used for supply chain and configuration management controls.	In: SBOM files and component lists.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Read-only connections

Connections to your cloud accounts and repositories use read-only permissions; the Accelerator does not change your systems.

Records kept in the United States

Package content and evidence for US government work are hosted in the United States region.

Cleared support lane

Support tickets from federal clients are routed only to US citizens with active security clearances.

Encryption under controlled keys

Client data is encrypted with keys Moraph staff cannot access without explicit, time-bound authorization.

Complete audit trail

Every draft, edit, approval, export and access grant is recorded with the user and time, and cannot be edited.

Independent audits

Moraph's controls are covered by its SOC 2 Type II report and ISO/IEC 27001 certification, available through the Trust Center.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Package readiness

Control status

For compliance lead and system owner

Every control in the baseline with its status: not started, drafted, in review, approved, or needing a person to write it.

Break down by: Control family, Status, Control owner, Implementation type
Delivered as: Live dashboard; CSV export
Used for: Seeing how far the package is from complete and where work is stuck.

Evidence coverage

For compliance lead and control owners

Which controls have current evidence, which rely on uploaded documents, and which evidence is older than the age you set.

Break down by: Control family, Evidence source, Evidence age, Control owner
Delivered as: Live dashboard; CSV export
Used for: Refreshing evidence before an assessment rather than during it.

Inherited controls

For compliance lead and assessor

Controls and parts of controls inherited from the infrastructure provider, with the source and the customer responsibilities that remain.

Break down by: Provider, Control family, Inheritance type
Delivered as: Live view; PDF and CSV export
Used for: Showing clearly what your organization implements and what it relies on.

Continuous monitoring

Configuration drift

For compliance lead, engineers and system owner

Changes detected since the last approved package version, the controls each one affects, and whether it has been reviewed.

Break down by: Component, Control, Change type, Review status
Delivered as: Live dashboard; scheduled email
Used for: Keeping the package in step with the system and deciding whether a change needs to be reported.

POA&M status

For compliance lead, system owner and assessor

Open and closed POA&M items with their source, severity, owner, milestones and status.

Break down by: Severity, Source, Owner, Milestone status, Period
Delivered as: Live dashboard; CSV and OSCAL export
Used for: Preparing the POA&M for continuous monitoring and tracking remediation.

Scan findings summary

For compliance lead and engineers

Findings imported from scanners in the period, how many were new, remediated or carried over, and how they map to POA&M items.

Break down by: Scanner, Severity, Asset type, Period
Delivered as: Live dashboard; CSV export
Used for: Preparing monthly continuous monitoring deliverables.

Monthly deliverables checklist

For compliance lead

The documents and data due for the period, which are prepared, which are approved and which have been sent.

Break down by: Deliverable, Status, Approver
Delivered as: Live view; scheduled email
Used for: Making sure nothing due for the month is missed.

Audit and history

Package version comparison

For system owner, assessor and agency reviewer

What changed between two package versions: statements, boundary components, parameters and evidence, with who approved each change.

Break down by: Control family, Change type, Approver
Delivered as: Live view; PDF export
Used for: Reviewing a significant change request or a new package version.

Statement approval history

For compliance lead and assessor

For each control, who drafted, edited and approved the statement, when, and what evidence it cited at the time.

Break down by: Control, User, Action, Date range
Delivered as: Live view; CSV and PDF export
Used for: Showing assessors that every statement was reviewed by a person.

Access and audit trail extract

For system owner and auditors

Who viewed, changed, approved or exported package content in a period, including assessor access.

Break down by: User, Action, Record, Date range
Delivered as: On request in the product; CSV export
Used for: Answering audit questions about who touched the package.

Exports, access and evidence

Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
Each report can be filtered and the filters saved, so the compliance lead and control owners can keep their own views.
Package, POA&M and component data are available in OSCAL and through the Moraph Work API for use in your own GRC or reporting tools.
Reports respect each viewer's role: control owners see their own controls, the compliance lead and system owner see the whole package, and assessors see only what has been shared with them.
Reports can be run as of a past package version and give the same result each time. Running and exporting a report is itself recorded in the audit trail.

Deployment

Where and how it runs

Moraph cloud, United States

Hosted in the United States region, with package content and evidence kept in the US.

Dedicated environment

A single-tenant environment for organizations that require isolation, scoped in the proposal.

With a managed service

Optionally run alongside Moraph's FedRAMP High Managed Landing Zone or another Moraph managed service for platform and continuous monitoring support.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Scoping

We agree the system, the target baseline and the likely boundary with your compliance lead and system owner, and identify the accounts, repositories and tools to connect.

Connections

Read-only connections are set up with your engineers. We need an engineer with authority to create read-only roles in each account and repository.

Boundary and inheritance

Discovered components are reviewed with you, the boundary is confirmed, and inherited controls from your infrastructure provider are recorded.

Existing documentation

Where you already have an SSP or policies, they are imported so drafted statements can be compared with what you have written.

Workflow and roles

Control ownership, review steps, roles and evidence age thresholds are configured to match how your team works.

Training and first package

Control owners and the compliance lead are trained on their own workflows, and we support the first full review cycle through to an approved package version.

Limitations

What it does not do

Worth knowing before you evaluate it.

The Accelerator does not grant or guarantee authorization. Authorization decisions are made by the authorizing official, and FedRAMP and agency review timelines are outside Moraph's control.
Moraph holds no FedRAMP authorization for this product. We provide control documentation to support your own authorization decision about using it.
It is not a third-party assessment organization and does not perform the independent assessment your authorization requires.
Drafted statements are only as complete as the configuration it can read. Procedural, personnel and physical controls need people to write them and supply evidence.
Every drafted statement must be reviewed by a person who knows the system; the Accelerator can misread intent from configuration alone.
It reads configuration but does not change it, and does not remediate findings.
It is not a vulnerability scanner. It imports results from the scanners you already use.
It is designed for FedRAMP and NIST SP 800-53 based authorizations. Other frameworks are not included unless scoped separately.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

Connect a non-production account and compare the drafted statements with the ones you have written
Ask a control owner to review a drafted statement and judge whether the cited evidence supports it
Change a setting in a test environment and check that the affected controls are flagged
Export a package version in OSCAL and validate it with your assessor's tools
Review which controls the Accelerator could not draft and how much remains for people to write
Confirm role separation: who can draft, approve and release a package version

Questions

Frequently asked questions

Does the Accelerator write the whole SSP for us?

No. It drafts statements where it can read supporting configuration and flags the rest for people to write. Every statement is reviewed and approved by your team before it goes into the package.

Will it get us authorized faster?

It reduces the manual work of writing and maintaining documentation and evidence. The assessment and the authorization decision, and their timelines, are outside Moraph's control.

Is the Accelerator itself FedRAMP authorized?

No. Moraph holds no FedRAMP authorization for this product. We provide control documentation to support your own decision about using it.

Does it change anything in our cloud accounts?

No. Connections are read-only. Changes to your systems are made by your engineers through your own processes.

Can we use it for an agency ATO rather than FedRAMP?

Yes. Agency authorizations based on NIST SP 800-53 follow the same workflow, with the baseline and tailoring your agency sets.

How is it priced?

As a subscription, usually measured by the number of systems and the baseline, with implementation charged separately. See Working with Moraph for what drives a quotation.

Next steps

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: FedRAMP ATO Accelerator guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: FedRAMP ATO Accelerator support guide.

FedRAMP ATO Accelerator

What you are buying

The problem it solves

Who uses it

Requirements it supports

A short walkthrough

Control status

A drafted statement

Drift detected

The POA&M

Package version

Sharing with the assessor

The principal workflows

Connect

Draft

Assemble

Monitor

Who does what in the product

Compliance lead

Sees

Does

Cannot

Control owner

Sees

Does

Cannot

Engineer

Sees

Does

Cannot

System owner

Sees

Does

Cannot

Assessor or agency reviewer (read-only)

Sees

Does

Cannot

Administrator

Sees

Does

Cannot

Permissions at a glance

How access is controlled

What it does

Configuration-based drafting

Boundary inventory

Control baselines

Inherited and shared controls

Evidence library

Drift detection

Review and approval

OSCAL output

POA&M tracking

Continuous monitoring

Package versions

Assessor access

How it connects to your systems

How your data is protected

Read-only connections

Records kept in the United States

Cleared support lane

Encryption under controlled keys

Complete audit trail

Independent audits

What you can report on

Package readiness

Control status

Evidence coverage

Inherited controls

Continuous monitoring

Configuration drift

POA&M status

Scan findings summary

Monthly deliverables checklist

Audit and history

Package version comparison

Statement approval history

Access and audit trail extract

Exports, access and evidence