Skip to main content
assurance support

The process

How verification works, end to end

From first submission to a public verification record — every step, and what happens when an application does not pass.

Phase 1 — Intake and scope

  1. Application intake

    You submit the application through the assessment request form. We review the submission, discuss your goals, and confirm which assurance level fits how the application will be used.

  2. Ownership confirmation

    We confirm that you own the application or are authorized to request the assessment. This protects builders from unauthorized reviews of their work and keeps the public registry trustworthy.

  3. Repository access

    You grant time-limited, read-only access to the source repository. Reviewers work under a confidentiality agreement, and access is revoked when the assessment concludes.

  4. Deployment access

    We arrange access to a representative deployment — ideally a staging environment that mirrors production — so reviewers can test the application as it actually runs.

  5. Scope definition

    Together we document the exact assessment scope: the application version and source commit, the deployment environment, the components in scope, and anything explicitly excluded. The final verification applies only to this documented scope.

Phase 2 — Independent technical review

  1. Automated scanning

    We run dependency, secrets, and static-analysis scans across the codebase to surface known vulnerability classes, exposed credentials, and outdated or risky packages.

  2. Manual code review

    Experienced developers read the code that matters most: authentication, authorization, data handling, input validation, and error paths. Automated tools miss what humans catch, and vice versa — we use both.

  3. Application testing

    Reviewers exercise the running application: attempting privilege escalation between roles, probing input handling, checking session behavior, and validating that security controls work in practice, not just in code.

  4. Architecture review

    We assess how the application is structured, deployed, and operated: data flows, trust boundaries, backup arrangements, logging, and whether another competent developer could maintain it.

  5. Findings classification

    Every finding is documented and classified by severity — critical, high, medium, or low — with the affected component, the potential impact, and a recommended fix.

Phase 3 — Remediation and decision

  1. Remediation period

    You receive the Developer Remediation Report and fix the findings — yourself, with a developer of your choice, or with an associated remediation team. We are available to clarify findings throughout.

  2. Independent retesting

    After remediation, a reviewer retests the application against every finding. If fixes were performed by an associated remediation team, a different reviewer conducts the retesting and makes the verification decision.

  3. Verification decision

    Applications that meet the standard receive a version-specific verification: Verified, or Verified with Conditions when specific ongoing obligations apply. Applications that do not yet meet the standard receive an updated remediation report — never a badge.

  4. Public registry

    The verification record is published to the public registry with the application identity, reviewed version, source commit, scope, status, conditions, and dates. Anyone can look it up at any time.

  5. Expiration and recertification

    Every verification carries an expiration date, typically six months from issue. Recertification is a streamlined re-review of the current version, focusing on what changed since the last assessment.

Material changes can invalidate verification

Verification applies to a specific version, source commit, and documented scope. A material change to the application — such as modified authentication, new data flows, significant architectural changes, or a new deployment environment — may invalidate the verification before its expiration date. Each record documents which changes must be submitted for reassessment.

Ready to see where your application stands?

The process starts with a conversation about your application and the right scope for your goals.

Request an Assessment Compare Assurance Levels