Continuous third-party assurance · Included in every edition

Continuous, verifiable compliance attestation between organizations

Share your live compliance posture with a customer, prime, bank or portfolio company on demand — instead of emailing a stale audit PDF or answering their security questionnaire. They get a current, trustworthy answer, and you stay in control of what is shared.

Get Flowing See how it works
  • Ed25519-signed
  • Both sides self-host
  • Verifies offline
Attestation validity
30 days
Attestation methods
4
Attestable over A2A
10
Shared cloud tenants
0

Built for entities that must keep assuring each other

Wherever one organization has to re-verify another's compliance and the questionnaire has stopped scaling, a signed on-demand query replaces the paperwork.

Parent ↔ subsidiary

Check each business unit's posture on demand. Every subsidiary keeps its own data.

Investor ↔ portfolio

Query a portfolio company's live control status before a follow-on tranche or a board review.

Prime ↔ subcontractor

Verify a subcontractor's CMMC Level 2 posture continuously, not once a year.

MSP ↔ clients

Publish a signed posture per managed tenant and let each client verify it themselves.

Network ↔ partner

Check a merchant's PCI DSS or a partner's SOC 2 status at onboarding, then whenever it matters.

Vendor ↔ customer

Give customers one endpoint to attest against, and query your own vendors exactly the same way.

What it replaces, and where it lives in the product

One posture, exposed on a machine surface and a human one, with a full trail of who asked.

The GRCFlow Vendor Portal, subtitled third-party risk management and A2A attestation monitoring: tiles for total vendors, critical tier, high risk and A2A connected, above a vendor table with tier, risk rating, data access, A2A status, next assessment and a Rotate Token action.

Retire the security questionnaire

A vendor record carries the counterparty's A2A status and its own service token, so third-party risk becomes a query instead of a spreadsheet round trip.

  • One protocol and schema for every counterparty, not a different form each time
  • Polled when it matters, rather than collected once a renewal cycle
  • Signed, so it cannot be edited in transit the way a returned document can
  • A NON_COMPLIANT or expired result is a value your own systems can act on
The GRCFlow Trust Center configuration screen: an Enable Trust Center toggle for public accessibility, display name, contact email, description, logo URL and primary colour fields, and a Section Visibility panel with a Compliance Score toggle.

The human counterpart: Trust Center

The A2A endpoint is the machine path. For prospects and auditors, GRCFlow also publishes a brandable page at your own /trust-center/<slug>.

  • Your frameworks, a compliance score and downloadable or NDA-gated documents
  • Per-section visibility, and an access-request workflow for gated files
  • Human-readable and unsigned, on purpose: the A2A endpoint is the verifiable path
The GRCFlow audit log, described in the product as a tamper-evident activity log with hash chain verification: rows of timestamp, action, entity type, entity id and SHA-256 checksum, with a Verify Chain Integrity button.

Share posture without losing visibility

Attestation events land in the same tamper-evident log as everything else in the platform, so you always know who asked for what, and when.

  • Every entry hash-chained and carrying its own SHA-256 checksum
  • Verify Chain Integrity re-checks the chain in place
  • A2A Alerts fan the same events out to your SIEM, with a 60-second redelivery sweep
The GRCFlow framework catalog: SOC 2 Type II, ISO/IEC 27001:2022, CMMC Levels 1 to 3 and NIST SP 800-171 Rev. 2 shown as cards with their control and category counts and a View Controls button, under tabs for catalog, cross-framework mapping, framework changes and assurance map.

What can be attested today

Control-backed posture for SOC 2, ISO/IEC 27001, PCI DSS, HIPAA and CMMC Level 2. The protocol recognizes ten framework identifiers; the rest join as their control mappings are added.

  • Status derived from your latest completed assessment of that framework
  • compliance/capabilities advertises what an instance can attest, and its key
  • All 20 frameworks and 2,082 controls ship in every edition; NIST SP 800-53 Rev. 5 alone is 1,014
Definition

What is continuous, machine-readable compliance attestation?

A compliance attestation is a statement that an organization's controls for a given framework are in place and operating. Historically it arrives point-in-time and by hand, as a SOC 2 report, an ISO 27001 certificate or a filled-in questionnaire, and goes stale the day it is filed.

A continuous, machine-readable attestation replaces that document with a live endpoint. A peer service calls POST /api/v1/a2a/mcp with the method compliance/attest and a framework name. GRCFlow answers with:

  • A status of COMPLIANT, PARTIAL, NON_COMPLIANT or NOT_ASSESSED
  • Counts of controls verified, compliant and non-compliant
  • An attestation proof: SHA-256 hash, Ed25519 signature, public key, algorithm and key id
  • A 30-day validity window, recomputed from your latest completed assessment on every request

In one sentence: GRCFlow, the AI-native, self-hosted GRC platform, turns your compliance posture into a signed, machine-readable attestation that any authorized counterparty's agent can request on demand and verify cryptographically, a continuous alternative to the annual questionnaire and the point-in-time audit PDF.

How the A2A (agent-to-agent) attestation exchange works

Two self-hosted instances, four steps, and nothing in between them holding both sides' data.

The A2A attestation exchange between two self-hosted GRCFlow instances Organization A, the relying party, posts an authenticated request to /api/v1/a2a/mcp on Organization B's own instance asking it to attest a named framework. B recomputes the answer from its latest completed assessment and returns an Ed25519-signed attestation carrying a status, control counts and a proof. A verifies that signature offline. Each side keeps its own database, evidence and signing key, and no shared cloud tenant sits between them. ORGANIZATION A PEER-TO-PEER, NO CENTRAL BROKER ORGANIZATION B RELYING PARTY Org A SELF-HOSTED GRCFLOW OWN DATABASE + EVIDENCE OWN AUDIT TRAIL HOLDS NO ORG B DATA ATTESTING PARTY Org B SELF-HOSTED GRCFLOW OWN DATABASE + EVIDENCE OWN AUDIT TRAIL OWN Ed25519 SIGNING KEY POST /api/v1/a2a/mcp "method": "compliance/attest" "params": { "framework": "SOC2" } 1 3 Ed25519-signed attestation status · controls verified / compliant / non-compliant proof: SHA-256 hash + signature + public key + key id expires_at: request time + 30 days 4 VERIFY Signature checked offline NO CALLBACK TO ANY SERVER 2 COMPUTE Latest completed assessment RECOMPUTED ON DEMAND NO SHARED CLOUD TENANT Neither instance stores the other's evidence. The only thing that crosses the boundary is the signed attestation itself.
The exchange is symmetric: whichever side is asked to prove posture answers, whichever side needs assurance verifies. Both roles ship in the same build. Swipe sideways to follow all four steps.
# A partner, parent company or TPRM agent asks your instance to attest SOC 2 POST /api/v1/a2a/mcp Authorization: Bearer <service-token> { "jsonrpc": "2.0", "method": "compliance/attest", "params": { "framework": "SOC2" }, "id": "1" } # ...your instance answers with a signed, machine-readable statement { "attestation_id": "att_…", "framework": "SOC2", "status": "COMPLIANT", "controls_total": 12, "controls_compliant": 12, "controls_non_compliant": 0, "expires_at": "…+30 days", "attestation": { "hash": "<sha256>", "signature": "<ed25519-hex>", "public_key": "<ed25519-pub>", "algorithm": "Ed25519", "key_id": "…" } }

Never anonymous

Token-authenticated with no anonymous fallback, rate-limited per service and per organization, and replay-protected with a per-request nonce.

Recomputed, not cached

Each call reads your latest completed assessment, kept current by continuous controls monitoring, and stamps a fresh 30-day validity window.

Every request logged

Issuances, denials, auth failures and replay attempts are all recorded, and can be fanned out to your SIEM.

Frequently asked questions

Direct answers about how multi-entity attestation works in GRCFlow, and where its honest limits are.

How do parent companies verify a subsidiary's SOC 2 or ISO 27001 compliance?

Parent companies verify it with a live query rather than a filed PDF. The subsidiary runs its own GRCFlow instance and exposes an A2A compliance-attestation endpoint; the parent's system sends a signed request asking to attest a named framework, and gets back a machine-readable statement of how many controls are passing, failing or unassessed for that framework, recomputed from the subsidiary's latest completed assessment and signed with the subsidiary's Ed25519 key. The parent verifies the signature against the subsidiary's public key, and can repeat the query any day rather than trusting a report that goes stale the moment it is filed. GRCFlow deliberately has no central parent-over-subsidiary org hierarchy, each entity keeps its own data on its own infrastructure, and the two instances exchange only the signed attestation.

What is machine-readable compliance attestation?

A machine-readable compliance attestation is a structured, signed statement of an organization's control posture that another system can request and parse automatically, instead of a human reading a PDF. In GRCFlow it is a JSON response to the A2A method compliance/attest: it names the framework (for example SOC 2 or ISO 27001), gives a status of COMPLIANT, PARTIAL, NON_COMPLIANT or NOT_ASSESSED, reports the count of controls verified, compliant and non-compliant, and carries an attestation proof, a SHA-256 hash of the canonical statement plus an Ed25519 signature and the signing public key, so the receiving system can confirm the statement is authentic and unaltered without trusting the transport.

How is continuous compliance attestation different from a security questionnaire?

A continuous attestation is a live endpoint the relying party queries whenever it needs the answer, whereas a security questionnaire is a point-in-time, self-reported document filled in once, manually reviewed, and out of date almost immediately. Because GRCFlow recomputes the attestation from your latest completed assessment on every request and stamps it with a 30-day validity window, the relying party always sees current posture rather than a snapshot from the last audit cycle. The result is also signed, so it cannot be edited in transit the way a returned questionnaire or a screenshot can, and it is standardized across counterparties rather than a different spreadsheet for every customer.

Does GRCFlow have a parent-subsidiary or portfolio organization hierarchy?

No, and that is a deliberate design choice. GRCFlow does not model a parent org that owns subsidiary orgs, and there is no central tenant that holds every entity's compliance data. Instead, each entity, the parent, each subsidiary, each portfolio company, each subcontractor, runs its own self-hosted GRCFlow instance and keeps its own evidence, risk register and audit trail on its own infrastructure. The multi-entity relationship lives in the A2A protocol: one instance requests a signed attestation from another and verifies it. This keeps data sovereign to each entity while still giving a parent, investor or prime contractor a verifiable, on-demand view of a counterparty's posture. Roll-up dashboards across many instances are something you build on top of those attestation queries, not an in-app org tree.

How do I verify a GRCFlow compliance attestation?

Every attestation carries an attestation proof: a SHA-256 hash of the canonicalized statement, an Ed25519 signature over it, the signing public key, the algorithm name and a key id. To verify, you canonicalize the attestation fields the same way (sorted-key compact JSON), check the SHA-256 hash matches, and verify the Ed25519 signature against the issuer's public key, all offline, with no call back to GRCFlow or to any license server. The A2A method compliance/verify performs this check for a previously issued attestation, and the compliance/capabilities method advertises which frameworks an instance can attest and which key it signs with.

Which compliance frameworks can be attested over A2A?

The A2A attestation responder returns a control-backed posture for SOC 2, ISO/IEC 27001, PCI DSS, HIPAA and CMMC Level 2 today; further frameworks are recognized by the protocol as their control mappings are added. The status it returns for a framework is derived from your latest completed assessment of that framework inside GRCFlow, which in turn draws on the platform's continuous controls monitoring, so the attested posture tracks your real assessment state rather than a hand-maintained claim.

Can a private-equity firm, bank or payment network gate access or capital on live compliance status?

Yes, that is the pattern the A2A protocol is built for. Because a counterparty's posture is available as a signed, on-demand query rather than an annual document, the relying party, an investor releasing a tranche, a bank onboarding a partner, a payment network verifying a merchant's PCI DSS status, an MSP or prime contractor before granting system access, can make that decision against current status and re-check it whenever it matters. GRCFlow provides the verifiable attestation and, through A2A Alerts, streams every attestation event to your SIEM; the business rule that turns a NON_COMPLIANT or expired attestation into a withheld payment or a revoked access grant is yours to enforce in your own systems.

Is the A2A attestation capability included in every GRCFlow edition?

Yes. A2A attestation and A2A Alerts are part of the base entitlements granted to every license, including the free 30-day trial key, there is no separate add-on or higher tier to buy for it. GRCFlow is self-hosted, so the attestation endpoint runs on your own infrastructure; you configure the Ed25519 signing key it uses, and the whole verification path works offline.

Next

Run the attestation endpoint yourself

A2A attestation and A2A Alerts are included in every edition, including the free 30-day trial key. Deploy on your own infrastructure and issue your first signed attestation.

Get Flowing Trust Center docs