Continuous, verifiable compliance attestation between related entities
Stop trading annual PDFs and security questionnaires. With GRCFlow's Agent-to-Agent (A2A) protocol, a parent company, investor, prime contractor, customer or automated third-party-risk system can request your compliance posture as a machine-readable, cryptographically signed statement — recomputed on demand and verifiable offline. Each entity self-hosts its own instance; the two attest to each other peer-to-peer.
What is continuous, machine-readable compliance attestation?
A compliance attestation is a statement that an organisation's controls for a given framework are in place and operating. Historically it is delivered point-in-time and by hand — a SOC 2 report, an ISO 27001 certificate, or a completed security questionnaire — reviewed once and filed until the next audit cycle, stale almost immediately.
A continuous, machine-readable attestation replaces that document with a live endpoint.
Instead of emailing a PDF, you expose a signed API that a counterparty can query whenever they need
the answer. GRCFlow does this through its Agent-to-Agent (A2A) protocol: a peer
service sends a request to POST /api/v1/a2a/mcp asking to attest a named framework, and
GRCFlow answers with a structured statement — the framework, a status of
COMPLIANT, PARTIAL, NON_COMPLIANT or NOT_ASSESSED,
the count of controls verified, compliant and non-compliant, and an attestation proof:
a SHA-256 hash of the statement plus an Ed25519 signature and the signing public key.
Because the statement is recomputed from your latest completed assessment on every request and carries a 30-day validity window, the relying party sees current posture, not a snapshot. Because it is signed, it cannot be edited in transit the way a returned questionnaire or a screenshot can. And because GRCFlow is self-hosted, the attestation endpoint runs on your own infrastructure — there is no shared cloud tenant holding every entity's data.
In one sentence: GRCFlow turns your compliance posture into a signed, machine-readable attestation that any authorised counterparty can request on demand and verify cryptographically — a continuous alternative to the annual questionnaire and the point-in-time audit PDF.
Continuous vendor compliance monitoring vs. questionnaires
The security questionnaire and the once-a-year report are the pain everyone in third-party risk complains about. Here is what changes when the attestation becomes a live, signed query.
Questionnaire & PDF (point-in-time)
- Self-reported, filled in by hand once per cycle
- Stale the moment it is filed; no signal if posture drifts
- A different spreadsheet for every customer or partner
- A returned document can be edited; hard to prove authenticity
- Manual chasing, review and re-collection every renewal
- Sits in an email thread or a shared drive
A2A attestation (continuous)
- Derived from your latest completed assessment, recomputed per request
- Queried on demand — always reflects current status, with a 30-day validity stamp
- One standard protocol and schema across every counterparty
- Ed25519-signed proof, verifiable offline against your public key
- No re-collection: the relying party polls the endpoint when it matters
- Every request and response streamed to your SIEM via A2A Alerts
How the A2A attestation exchange works
A symmetric, peer-to-peer protocol between two self-hosted instances (or any A2A-speaking service). Whichever side is being asked to prove posture answers; whichever side needs assurance verifies.
Request
The relying party sends an authenticated JSON-RPC request to POST /api/v1/a2a/mcp with method compliance/attest and the framework it wants attested.
Compute
GRCFlow reads the responder's latest completed assessment for that framework and tallies controls verified, compliant and non-compliant — kept current by continuous controls monitoring.
Sign
It canonicalises the statement, hashes it with SHA-256, signs it with an Ed25519 key you control, and returns the attestation with its proof and a 30-day expiry.
Verify
The relying party checks the hash and verifies the Ed25519 signature against the public key — offline, no callback. compliance/verify re-checks an issued attestation.
Requests are token-authenticated with no anonymous fallback, rate-limited per service and per organisation, and replay-protected with a per-request nonce. Fields shown are the real schema; values are illustrative.
Built for related entities that must continuously assure each other
Wherever one organisation has to keep verifying another's compliance — and the questionnaire has stopped scaling — a signed, on-demand attestation replaces the paperwork.
Holding companies & conglomerates
Verify each subsidiary's SOC 2, ISO 27001 or PCI DSS posture on demand instead of collecting a report from every business unit once a year. Each subsidiary keeps its own data sovereign.
PE & VC portfolio assurance
Query a portfolio company's live control status before a follow-on tranche or a board review — and gate capital or access on a current, signed attestation rather than a stale attestation letter.
Defence & government supply chain
Prime contractors verify a subcontractor's CMMC Level 2 posture continuously today; NIST SP 800-171 and FedRAMP are recognised by the protocol with control mappings on the roadmap.
MSPs & MSSPs
Publish a signed posture per managed tenant, and let each client verify it themselves rather than answering the same questionnaire from every one of them.
Banks & payment networks
Verify a merchant's or partner's PCI DSS / SOC 2 status as a live query during onboarding and on an ongoing basis, and turn a NON_COMPLIANT or expired attestation into an enforced business rule.
Third-party / vendor risk
Kill the vendor security questionnaire: give customers a standard endpoint to attest against, and query your own vendors the same way. A vendor record can store a counterparty's A2A endpoint.
One posture, two surfaces — and a full alert trail
GRCFlow exposes your compliance posture to the outside world in two complementary ways, and logs every machine request so your security team sees it.
A2A attestation endpoint
The signed, machine-readable path. A counterparty's system queries /api/v1/a2a/mcp
and verifies an Ed25519 proof — no human in the loop, no document to parse.
This is the path to build automated portfolio roll-ups, onboarding gates and continuous TPRM on.
Trust Center
A public, brandable page at your own /trust-center/<slug> showing your frameworks,
a compliance score and downloadable or NDA-gated documents, with an access-request workflow.
This is the human-readable counterpart for prospects and auditors. It is not cryptographically signed — the A2A endpoint is the verifiable, machine path.
A2A Alerts → your SIEM
Every attestation request, issuance, denial, auth failure or replay attempt is recorded and can be routed to your SIEM over an HMAC-SHA256 signed webhook or email, with a redelivery sweep.
So sharing posture never means losing visibility into who asked for what, and when.
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?
The traditional way is a point-in-time artefact: the subsidiary emails a SOC 2 report or a completed security questionnaire, and the parent files it until next year. With GRCFlow the subsidiary runs its own 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. It is a live query the parent can repeat any day, not a PDF 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 organisation'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 security questionnaire is a point-in-time, self-reported document: someone fills in a spreadsheet or a portal once, it is manually reviewed, and it is out of date almost immediately. A continuous attestation is a live endpoint the relying party queries whenever it needs the answer. 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 standardised across counterparties rather than a different spreadsheet for every customer.
Does GRCFlow have a parent-subsidiary or portfolio organisation 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 canonicalised statement, an
Ed25519 signature over it, the signing public key, the algorithm name and a key id. To verify, you
canonicalise 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 licence 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 recognised 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 licence, 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.
Run the attestation endpoint yourself
Take a free 30-day trial key — no credit card — deploy GRCFlow on your own infrastructure, and issue your first signed compliance attestation. A2A is included in every edition.