Assurance.Support Software Assurance Standard

The published methodology behind every verification. Fifteen domains covering security, reliability, maintainability, and operational readiness — applied at increasing depth across the three assurance levels.

Application Identity and Scope

Every assessment is anchored to an unambiguous definition of what is being reviewed.

The application, version, and source commit under review are precisely identified.
The deployment environment and in-scope components are documented.
Exclusions are stated explicitly in the assessment scope and the public record.

Source Code and Ownership

The applicant must control the code being verified.

The applicant demonstrates ownership of, or authorization over, the application.
The reviewed source corresponds to the deployed application.
Third-party and licensed components are identified and used consistently with their licenses.

Architecture and Maintainability

The application can be understood, operated, and modified by a competent developer other than its author.

The overall structure, data flows, and trust boundaries can be documented coherently.
Code organization and naming support maintenance by another developer.
Configuration is separated from code, and environments are reproducible.

Authentication and Authorization

Access to the application and its data is controlled and enforced.

Authentication follows current, generally accepted practices for credential handling and session management.
Authorization is enforced on the server for every protected resource and action.
Role and permission boundaries behave as documented under testing.

Data Protection

Data entrusted to the application is protected in transit and at rest.

Transport encryption is enforced for all application traffic.
Sensitive data at rest is protected appropriately to its sensitivity.
Personal and business data is not exposed through logs, errors, or debug output.

Secrets and Credential Management

Keys, tokens, and credentials are stored and handled safely.

No secrets are committed to source control or exposed to clients.
Secrets are stored in a managed mechanism appropriate to the deployment platform.
Credentials can be rotated without code changes.

Dependency and Supply-Chain Risk

Third-party components are known, current, and monitored.

Dependencies are inventoried and scanned for known vulnerabilities.
Components with known critical vulnerabilities are remediated or formally risk-accepted with justification.
A process exists for applying security updates.

API and Input Validation

The application treats all external input as untrusted.

Inputs are validated and outputs are encoded to prevent injection classes of vulnerability.
APIs enforce authentication, authorization, and rate limiting appropriate to their exposure.
Error responses do not leak internal implementation details.

Logging and Monitoring

Operators can tell what the application is doing and when something goes wrong.

Security-relevant events (sign-ins, permission changes, failures) are logged.
Logs exclude secrets and unnecessary personal data.
A mechanism exists to detect and surface application errors.

Backup and Recovery

Data can survive failure, and recovery has actually been exercised.

Backups run automatically and cover all data the business depends on.
Restore procedures are documented and have been tested, not assumed.
Recovery objectives are stated and achievable with the current arrangement.

Testing and Quality Controls

Changes can be made without silently breaking what works.

Meaningful automated tests cover the application’s critical paths.
Tests run before deployment through a repeatable process.
Known defects are tracked rather than undocumented.

Deployment and Rollback

Releases are repeatable, and a failed release can be undone.

Deployment is scripted or otherwise repeatable, not a manual ritual.
A documented rollback path exists and has been exercised.
The deployed artifact can be traced to a specific source commit.

Documentation and Operational Readiness

The people who operate and inherit the application have what they need.

Setup, configuration, and deployment are documented well enough for another developer to take over.
Operational runbooks cover routine tasks and common failure modes.
Administrative access and third-party service dependencies are documented.

Findings, Remediation, and Retesting

Issues found during review are resolved and independently confirmed.

All critical and high-severity findings are remediated before verification.
Medium and low findings are remediated or formally accepted with documented rationale.
Remediated findings are confirmed by independent retesting, separated from any associated remediation work.

Verification Status and Expiration

Verification is current, honest, and checkable.

Every verification carries explicit issue and expiration dates.
Material changes to the application are submitted for reassessment.
The public record reflects the current status, including suspension or revocation.

About this standard

The Assurance.Support Software Assurance Standard is an independent methodology developed and maintained by Assurance.Support. It may reference established industry practices, but it is not affiliated with, endorsed by, or a substitute for any external standard, framework, or government program. Verification against this standard does not constitute legal or regulatory certification. Detailed assessment criteria are provided to applicants during scoping.

See how your application measures up.

Every assessment applies this standard at the depth of your chosen assurance level.

Request an Assessment Compare Assurance Levels