Skip to content
ECZ-IDMCP

Deliverables

The Production Evidence Pack

Every engagement on this site ends with the same flagship deliverable: a structured evidence pack your engineering, security and procurement reviewers can actually assess — scope, findings, reproducible test records, a residual-risk register and a full access history, plus deployment runbooks and rollback plans where implementation is in scope.

Consultancy that ends in a slide deck leaves your reviewers with nothing to check. Ours ends in documents with evidence attached — because “trust us” is not something a security or procurement team can file.

See a sample finding

A synthetic example, not a customer finding.

The common spine

The spine every edition is built from

Each service delivers its own edition of the pack. Most items appear in all four editions; the deployment runbook and rollback plan appear where implementation is in scope. Every row names its intended audience and its applicability, so nothing has to be assumed.

Production Evidence Pack contents, intended audience, purpose and which engagements include each item
ItemForApplies toPurpose
Scope statement & exclusionsEngineering, procurementEvery engagementExactly what was covered, what was not, and why.
Findings or design documentationEngineering, securityEvery engagementSeverity-ranked findings (audit) or architecture and design rationale (implementation engagements).
Client verification recordEngineering, QAEvery engagementThe named clients tested, the agreed conditions, and the recorded results — reproducible, not anecdotal.
Residual-risk registerSecurity, procurementEvery engagementWhat remains open at handover, why it was not closed, who owns it, and what would close it.
Deployment runbook & rollback planOperationsImplementation engagementsHow to deploy the change safely, and the documented path back if something goes wrong.
Security & access recordSecurityEvery engagementWhat access was granted, how credentials were handled, and confirmation of removal at handover.
Methodology & limitations noteSecurity, procurementEvery engagementWhat was examined and what was not — so nobody relies on coverage that was never claimed.

The deployment runbook and rollback plan apply where implementation is in scope. The Readiness Audit makes no code change, so it assesses deployment and rollback posture rather than producing those documents. The Enterprise Pilot additionally exercises the rollback in a non-production environment.

The methodology and limitations note matters as much as the findings: it states what was examined and what was not, so nobody relies on coverage that was never claimed.

Editions by service

What each engagement adds to the spine

The four services produce four editions of the pack, each shaped by the work actually done — an audit documents findings; a migration documents the change and how to reverse it; identity and enterprise work document design, review and pilot results.

MCP Readiness Audit

One fixed fee, agreed in writing before the audit begins.

Evidence pack contents

  • Findings report (PDF and Markdown).
  • Remediation plan with priority ordering.
  • Client compatibility matrix with test conditions recorded.
  • Requirements, findings and acceptance traceability matrix.
  • Residual-risk register: what remains open, who owns it and what would close it.
  • Scope statement and exclusions as agreed at kickoff.
  • Methodology note describing what was and was not examined.

The pack is one of 5 deliverables listed for this service.

Full scope, exclusions and pricing

Stateless Migration Sprint

Two milestones — one on reservation, the balance on acceptance against the agreed criteria.

Evidence pack contents

  • Scope statement and change-control record.
  • Architecture before/after summary.
  • Before/after state and authorisation data-flow summary.
  • Change log and pull-request review summary.
  • Test suite results and how to reproduce them.
  • Client verification record with test conditions.
  • Requirements, findings and acceptance traceability matrix.
  • Residual-risk register: what remains open, who owns it and what would close it.
  • Directory metadata and ownership readiness checklist — readiness assistance only, with no directory-acceptance promise.
  • Deployment runbook and documented rollback plan.

The pack is one of 5 deliverables listed for this service.

Full scope, exclusions and pricing

EMA/ID-JAG Design & Pilot

An initial milestone to start the design, then a written scope after design review. No further milestone is due before that written confirmation.

Evidence pack contents

  • Architecture document with identity-boundary diagrams.
  • State and authorisation data-flow summary.
  • Authorization design rationale (scopes, audiences, token-exchange flows).
  • Pilot test record with conditions and results.
  • Negative authorisation test record: wrong issuer, wrong audience, expiry, replay and insufficient permission.
  • Requirements, findings and acceptance traceability matrix.
  • Residual-risk register, including dependencies on your identity provider.
  • Security-review notes and resolved actions.
  • Hardening and rollout roadmap.

The pack is one of 5 deliverables listed for this service.

Full scope, exclusions and pricing

Enterprise MCP Pilot

Three milestones — reservation, the implementation milestone defined in the written scope, and acceptance.

Evidence pack contents

  • Architecture and design documentation.
  • State and authorisation data-flow summary.
  • Security and identity review record.
  • Interoperability and acceptance test records with conditions.
  • Negative authorisation test record: wrong issuer, wrong audience, expiry, replay and insufficient permission.
  • Requirements, findings and acceptance traceability matrix.
  • Residual-risk register: what remains open, who owns it and what would close it.
  • Deployment runbook and rollback exercise record.
  • Directory metadata and ownership readiness checklist — readiness assistance only, with no directory-acceptance promise.
  • Operational guidance: logging, monitoring and incident basics for the pilot.
  • Procurement appendix: scope, dependencies, data handling, subprocessors and specialists, support boundaries and exclusions.

The pack is one of 8 deliverables listed for this service.

Full scope, exclusions and pricing

Honest boundaries

What deliverables are — and are not

Reviewers need to know exactly what weight a document can bear. So we state both sides plainly, in the pack itself and here.

Deliverables are

  • Evidence and documentation: what was examined or built, what was found or changed, and the reasoning behind every recommendation.
  • Reproducible test records: the named clients exercised, the exact conditions agreed in scope, and the recorded results — pass or fail.
  • Severity-ranked findings with the evidence for each, so your engineers can verify a finding rather than take it on trust.
  • Where implementation is in scope, runbooks and rollback plans written for your team to execute without us in the room.
  • A residual-risk register: what remains open at handover, why, who owns it, and what would close it.
  • A record of the access granted for the engagement, how credentials were handled, and confirmation of removal at handover.

Deliverables are not

  • Not a certification, accreditation or regulatory approval of any kind.
  • Not a compliance attestation — the pack gives your compliance function evidence to assess, not a conclusion to copy.
  • Not a security guarantee, and not a penetration test report — audits assess code, configuration and design, and say so explicitly.
  • Not a promise of compatibility with every MCP client — verification covers the clients named in the written scope, nothing broader.
  • Not a substitute for your own security and procurement review — it is built to make that review faster and better informed.

EcoCitizenz does not provide certification, compliance attestation or security guarantees, and says so rather than implying otherwise. The evidence pack gives your reviewers material to evaluate — it does not replace their judgement, and is not designed to.

Formats & handover

Delivered in formats your team already works in

A deliverable only counts if your team can find it, search it, version it and act on it a year later — without asking us.

PDF and Markdown, always both

Every written deliverable is supplied as a PDF for circulation to reviewers and as Markdown source, so it can live in your repository or wiki — searchable, diffable and yours to maintain.

Runbooks live in your repository

For implementation engagements, deployment runbooks and rollback plans are committed alongside the code they describe, so operational documentation versions with the system instead of drifting from it.

Walkthrough sessions, not a file drop

Deliverables are walked through live with your team — a findings walkthrough for the audit, handover sessions for implementation work — so questions are answered before the engagement closes.

Access removed, and confirmed

At handover, the access granted for the engagement is removed and the removal is confirmed to you. The security and access record in the evidence pack documents what was granted, when, and when it ended.

EcoCitizenz may use appropriately vetted specialists or subcontractors to support delivery. EcoCitizenz remains responsible for the agreed deliverables. Any specialist access to customer systems or confidential information will be disclosed and governed by the engagement terms.

Free, permanent, and yours either way

Your organisation's ECZ-ID Business Passport

Your organisation's ECZ-ID Business Passport is free and permanent at the Declared tier: a machine-readable business profile for the emerging agent and machine economy, with a public Resolver page that people and software can read for themselves. A paid engagement is delivered against it, and never the way you get it — and it adds 90 days of Verified access on top.

  1. Identity first

    Your organisation's Business Passport record is free and permanent, and you do not have to buy anything to hold one. If you already have an ECZ-ID, an engagement uses it rather than creating a second.

  2. Setup

    If you do buy an engagement, your order automatically starts account setup. There is nothing to apply for and no approval step — setup begins on its own.

  3. Activation

    When setup completes, a DECLARED Parent record is created and activated automatically if your organisation did not already hold one. DECLARED records what you say about yourself, with the date you said it.

  4. Resolver profile

    Your live ECZ-ID profile is available through the Resolver. You control what it says — optional profile information and bindings are managed by you through TrustOps.

  5. 90 days of Verified

    A paid engagement also includes 90 days of Verified Parent access, which is the paid tier above Declared. That period starts at activation and does not renew: there is no automatic charge at day 91. Your ECZ-ID itself is unaffected either way — it was already permanent.

What a reader can tell apart

The distinction below is the point of the page. Anything that blurred these four would be worse than publishing nothing.

Verified
Checked by ECZ-ID against a defined check. The check that was run is identifiable.
Self-declared
Supplied by the holder and published as their statement. Useful, and not independently checked.
Bound
Cryptographically or operationally tied to a control the holder demonstrated, such as a domain or an endpoint.
Referenced
Points at something maintained elsewhere. It is only ever as current as that source.

Who it is useful to

Insurers

A stable, resolvable reference for who you are and what you operate, instead of a PDF attached to an email thread.

Regulators and auditors

A dated, read-only projection they can check themselves, with the basis of each field visible.

Procurement

Somewhere to send a vendor-verification question that does not require you to be awake to answer it.

Customers

A way to confirm they are dealing with the business they think they are dealing with.

Partners

A durable identifier to reference in integrations and agreements rather than a marketing URL that changes.

Agents and software

A machine-readable profile an automated buyer can resolve and reason about, with each field's basis machine-distinguishable.

How useful any of that is depends on the information and bindings you maintain. A Resolver page does not prove compliance, and it does not make its holder the right choice — it lets a reader check specific things for themselves and see what has actually been checked.

Free and permanent, with or without an engagement. See how Resolver proof works (external). See the technical documentation for ECZ-ID evidence-state definitions.

Choose the engagement — the evidence pack comes as standard

Every price is published, every scope is fixed in writing, and every engagement ends in the documentation described on this page. If you want to see how it is produced stage by stage, read the delivery method.

Your delivery schedule is confirmed during intake.

More on ECZ-ID MCP