NZ Government Procurement
If your team is providing QA services to a government agency — or you're the Test Manager inside one — you need to understand how the procurement process works. It determines your mandate, your scope, and often your methodology.
1 The Hook
A Wellington QA consultancy wins a contract to test a new Ministry of Education digital service. Three months in, the Ministry's privacy team discovers the contractor's test environments contain real student PII — names, IRD numbers, and learning difficulties data. The contractor assumed test data masking was "the client's problem." The RFP said nothing specific about it.
Under the NZ Privacy Act 2020, the Ministry bears responsibility as the data controller. The incident results in a variation to the contract, a six-week pause for remediation, and a notification to the Office of the Privacy Commissioner. The pause costs the programme $340,000 and delays the go-live by two months.
The RFP should have included a test data requirements clause. The Test Manager who wrote the scope for the RFP response should have raised it. They didn't. That's a skill gap this lesson fixes.
2 The Rule
"When you write the QA scope for a government RFP response, you are writing a legal obligation. Everything you don't explicitly exclude, you own."
3 The Analogy
Government procurement is like a building consent process.
You submit plans (your proposal). The council (the agency) assesses compliance with the rules — Government Rules of Sourcing, NZISM, Privacy Act. Once consented (contracted), every deviation is a variation. Variations cost money and trust. The council doesn't care that you didn't understand the rules — the consent is the contract, and the contract is the standard.
4 Watch Me Do It
Here's how to read a GETS listing and structure the quality section of your RFP response.
Reading a GETS listing
GETS (Government Electronic Tenders Service) at gets.govt.nz publishes all government procurement over $100,000. Every listing has: a Request for Proposal document, evaluation criteria (weightings), and a mandatory questions section. Find the evaluation criteria before you read anything else — they tell you what the agency will pay for.
Standard sections in a quality RFP response
1. Scope
What you will test, what you won't, and how you define the boundary. Be explicit. "We will test functional requirements as specified in the SRS. Performance and penetration testing are out of scope unless separately agreed."
2. Methodology
Which standard you align to. "Our methodology is aligned to ISTQB CTAL-TM v3.0 and ISO/IEC 29119." Note: write "aligned to" — not "certified under" — unless you have a formal third-party certification.
3. Test data management
How you handle PII in test environments. Reference the Privacy Act 2020 obligations. State explicitly: "All test data will be synthetic or masked production data. No unmasked PII will be used in test environments without written agency approval." This clause prevents the Wellington scenario above.
4. Environment controls
Reference the NZISM controls applicable to your test environments (access control, encryption at rest, audit logging). If the agency holds data at a specific NZISM classification, your test environment must meet or exceed that classification.
5. Accessibility
Reference NZ Web Accessibility Standard 1.2 (based on WCAG 2.1 AA). Government services must meet this standard. Confirm your test plan covers accessibility testing across all user-facing components.
6. Sign-off governance
Who approves exit from each test phase. A government programme will require named agency sign-off, not just vendor self-certification. Propose the structure in the RFP response so it doesn't surprise either party after contract award.
5 When to Use It
- Writing the quality section of a government RFP response
- Reviewing a contract before signing — check that quality obligations are symmetrical between both parties
- Scoping a test programme for a government client where the Statement of Work is vague
- Advising a client on whether a vendor's quality claims in their RFP response are verifiable
- Onboarding to a government programme mid-flight — understanding the contract scope protects you from inheriting obligations you didn't know existed
6 Common Mistakes
⚠ "The procurement team handles the contract, not me."
I used to think: The procurement team handles the contract, not me.
Actually: The quality scope in an RFP response is a technical document. Procurement teams don't know what "test data masking" means. If you don't write it in, it's not in scope — and you'll own the consequences.
⚠ "Listing ISO certifications makes the proposal stronger."
I used to think: Listing ISO certifications makes the proposal stronger.
Actually: Claiming ISO/IEC 29119 certification when you follow the principles but haven't been audited is a misrepresentation. Write "aligned to" or "based on" — not "certified." A savvy evaluator will ask for your certificate number.
⚠ "NZISM is only relevant to security testing."
I used to think: NZISM is only relevant to security testing.
Actually: NZISM controls apply to test environments holding government data. A test environment with production data is subject to the same controls as production — including access control, audit logging, and encryption at rest.
7 Now You Try
Send the prompt below to a real AI and evaluate whether the response covers all required elements. Edit it to be more specific before sending.
8 Self-Check
Click each question to reveal the answer.
Q1: What is GETS and why does it matter to a Test Manager providing services to government?
GETS (Government Electronic Tenders Service) is the NZ government's public procurement portal at gets.govt.nz. All government contracts over $100,000 are listed there. As a Test Manager, you use GETS to find RFPs in your space, understand evaluation criteria before writing your proposal, and benchmark what competitors are likely to claim. The GETS listing also tells you which mandatory standards the agency has committed to — which flow directly into your quality scope.
Q2: What is the Government Rules of Sourcing (GRS) and which clause most affects QA scope?
The Government Rules of Sourcing (GRS) is the procurement policy framework that all government agencies must follow. Rule 58 (Value for money) requires that contracts define measurable quality outcomes — not just activity. For a QA engagement, this means your contract must specify what "quality" looks like (defect rates, coverage metrics, exit criteria) — not just that you'll "do testing." This is why vague quality scope is a contract risk.
Q3: A client asks you to confirm you are "ISO 27001 certified." You follow ISO 27001 practices but haven't been audited. What do you say?
You say: "We are aligned to ISO 27001 — our controls, policies, and processes reflect the standard. We have not undergone a formal third-party certification audit. If certification is a contractual requirement, we can discuss a pathway to achieve it." Do not claim certification you don't hold. Misrepresentation in a government tender is grounds for disqualification and potential legal liability.
9 ISTQB Mapping
CTAL-TM v3.0 — Section 2.4: Test Policy and Strategy
Applies when defining quality obligations in a contract. The test policy section of a government proposal is not a marketing document — it is the contractual baseline for what "quality" means on the engagement. CTAL-TM v3.0 Section 2.4 covers how to establish and communicate testing policies that are enforceable, measurable, and aligned to organisational risk appetite.
CTAL-TM v3.0 — Section 6.1: Test Manager Skills
Includes stakeholder management and contractual awareness as Test Manager competencies. A Test Manager who cannot read and contribute to a procurement document is not operating at full seniority. Section 6.1 frames contractual and regulatory literacy as professional obligations, not optional extras.