Quality Policy

1. Purpose

This policy describes the quality management system National Digital uses to ensure the software we build and maintain meets client requirements, is fit for purpose, and can be safely changed over the life of the engagement.

National Digital does not hold third-party certification to AS/NZS ISO 9001. Our quality system is documented here and is enforced primarily through automated controls in our engineering platform rather than through manual sign-off.

2. Quality commitment

We commit to:

• Understanding what the client is actually trying to achieve before proposing how to build it
• Delivering software that meets agreed requirements and behaves correctly under real conditions
• Preventing defects through automated verification rather than detecting them after release
• Correcting defects we introduce at our own cost
• Continuously improving our practices based on what goes wrong

3. How quality is controlled

3.1 Requirements and scope

Work begins with a written statement of what is to be built and what "done" means. Requirements are recorded as tracked issues in Jira, one per unit of work, with acceptance criteria written so they can be tested by someone other than the author. Changes to scope are recorded against the issue rather than absorbed silently.

3.2 Version control and traceability

All source code is held in Git repositories under organisational control. Every change is traceable to an authenticated author, a tracked issue and a point in time. Nothing reaches a client environment except through this path — there is no direct editing of production systems.

3.3 Peer review

No change reaches a production system without review by someone other than its author. Review is enforced by branch protection rules: the platform will not permit an unreviewed change to be merged.

3.4 Automated testing and continuous integration

Every proposed change triggers an automated pipeline that builds the application and runs the test suite. A change that fails the pipeline cannot be merged. Test coverage is written alongside the feature, and defects found in production are reproduced by a failing test before being fixed, so the same defect cannot silently return.

3.5 Quality assurance gate

Changes carry an explicit QA state. A change cannot be merged until it has been tested against its acceptance criteria and marked as QA complete by a reviewer, with that state recorded against the tracked issue. This gate is applied uniformly across all client repositories and is enforced by the platform.

3.6 Staged environments

Changes are promoted through development and staging environments that mirror production configuration before reaching production. Client-facing acceptance is performed in staging, on real data structures, before release.

3.7 Release and rollback

Releases are automated and repeatable, producing the same result each time they are run. Every release is identified by the exact revision deployed, so the running state of any environment can be established at any time. Where a release causes a defect, we can revert to the prior known-good revision.

3.8 Monitoring and defect response

Production systems are monitored for availability and error conditions. Defects are triaged by severity: those affecting availability or data integrity are addressed immediately; others are scheduled transparently with the client. Root cause is recorded for significant incidents, and the corrective action is a change to whatever in the system or the process let the defect through.

3.9 Security and privacy as quality attributes

We treat security and privacy defects as quality defects. Credentials are never committed to source control; access to client systems is granted per person and revoked on departure; administrative interfaces are placed behind authenticated access rather than exposed publicly.

4. Responsibilities

The CEO owns this policy and the engineering standards it describes, and is accountable for delivery quality to clients.

The COO oversees delivery management, issue tracking and client acceptance.

Every engineer, employed or contracted, is responsible for the quality of their own work, for writing tests alongside code, for reviewing others' work honestly, and for raising rather than concealing a problem they have found or caused.

Contracted engineers work inside the same controls as employees, using our repositories, pipelines and review gates.

5. Client feedback and complaints

Client feedback is sought continuously through regular delivery check-ins rather than only at project close. Any client dissatisfaction is escalated to the CEO, acknowledged directly, and answered with a specific remedy and timeframe. Where we are at fault, we say so and fix it at our cost.

6. Continuous improvement

We review recurring defects and incidents to identify systemic causes, and change our standards, templates or automated checks in response. Improvements are applied across all repositories rather than only to the project where the problem surfaced.

7. Review

This policy is reviewed annually, and additionally following any significant delivery failure or material change to our engineering practices.

Cameron Young Chief Executive Officer, National Digital 17 August 2026