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, Revenue NZ 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.
Senior engineer insight
The single most important shift in how I think about government procurement is this: the RFP response is not a sales document, it is the first draft of your test strategy. Every evaluation criterion the agency publishes maps directly to a test obligation you'll be held to post-award. Once I started reading GETS listings through that lens — translating "vendor must demonstrate secure data handling practices" into specific test environment controls before I wrote a single word of the response — the number of painful contract variations we had to manage dropped sharply.
The most common mistake: writing the quality section last, as a boilerplate paragraph, after the commercial team has already committed to a fixed price and timeline that assumed none of the government-specific obligations.
From the field
We were brought in mid-programme on a MBIE digital identity project that had been procured through an AoG panel. The incumbent Test Manager had scoped the engagement against the vendor's own test framework — a perfectly competent framework, but one that had no reference to NZISM controls or the NZ Web Accessibility Standard. When the agency's security team ran their own assessment before go-live, they found the test environment holding masked production data was classified at NZISM Restricted but controlled at a lower baseline. The programme had to pause for six weeks while environments were rebuilt. What stung most was that the original GETS listing explicitly referenced NZISM as a mandatory standard — it was just never translated into test scope.
The lesson: when you join a government programme mid-flight, the first thing you read is the original GETS listing and the contract's Statement of Work, not the current sprint backlog. The procurement document tells you what "done" legally means.
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.
Why teams fail here
- Treating the GETS listing as background reading rather than a binding obligation register — evaluation criteria in GETS are the contract's quality expectations in embryonic form, not a marketing wishlist.
- Conflating "we are on the AoG All-of-Government supplier panel" with "we automatically meet this agency's quality requirements" — panel membership proves commercial eligibility, not technical fitness for the specific programme.
- Leaving test data governance out of the RFP response because it feels like an operational detail — under the Privacy Act 2020, unmasked PII in a test environment is a notifiable privacy breach regardless of which party's staff caused it, and the agency as data controller will name the vendor in the OPC notification.
- Writing "aligned to NZISM" without specifying which classification tier the test environments must meet — a GETS evaluator with a security background will interpret the omission as an admission that you haven't read the standard, and it is often enough to disqualify an otherwise strong proposal.
Key takeaway
In NZ government procurement, your RFP response is not a promise to try — it is a legal definition of what quality means on this engagement, and everything you leave vague will be interpreted against you when the contract is tested under pressure.
Senior engineer insight
The most counterintuitive thing I learned about AoG panel contracts is that being on the panel is the floor, not the ceiling — the agency still writes its own Statement of Work and can impose obligations far tighter than anything the panel deed covers. I once had a client assume that our GCIO Information Technology panel membership meant NZISM compliance was automatically in scope; it wasn't written anywhere. When the agency's security assurance team arrived for a pre-go-live review, we had test environments that didn't meet Restricted classification requirements, and we owned the remediation cost because our SoW had no carve-out. That experience changed how I approach every government engagement: I now read the originating GETS listing, the panel deed, and the project SoW as three separate, sometimes contradictory documents — and I document where they conflict before signing.
Most common mistake: Test Managers assume that contract variations for government work are negotiable the way they are in private sector — they're not. Under the Government Rules of Sourcing, variations require documented justification and chief executive or delegate approval, which means what you didn't scope in your original response stays out of scope for months, not days.
From the field
We responded to a GETS RFP for a Benefits NZ case management replacement — competitive process, three shortlisted vendors, formal oral presentations. Our quality section was thorough: ISTQB-aligned methodology, ISO/IEC 29119 test documentation, privacy impact assessment process. We were ranked second. The debrief told us the winning vendor had explicitly named the NZ Web Accessibility Standard 1.2 and included a WCAG 2.1 AA test matrix as an attachment to their quality section. We had written "accessibility testing will be performed in line with relevant NZ standards" — the same thing in four words instead of four pages. The evaluators couldn't score us on it because we gave them nothing to score. The lesson generalises everywhere: in any structured evaluation, an unstated commitment is a zero, regardless of your intent or capability.
Why teams fail here
- Treating GETS evaluation criteria as a scoring rubric to optimise rather than a list of contractual obligations — you win the tender by writing what evaluators want to read, then discover six months in that you're legally bound to deliver every word of it.
- Delegating the quality section of an RFP response entirely to a bid writer — bid writers know structure and tone; they don't know that "test environment" under NZISM Restricted means dedicated infrastructure with audit logging, not a shared cloud tenant.
- Entering an AoG panel engagement without reading the specific call-off SoW as carefully as the panel deed — the deed sets the commercial framework, but the SoW is what you'll be audited against, and agencies routinely include bespoke security or accessibility requirements not present in the panel terms.
- Assuming the agency's project manager will flag compliance gaps — in NZ government procurement, the agency is the data controller and the regulatory obligee, but enforcement of vendor quality obligations is the Test Manager's professional responsibility, not the agency PM's operational task.
Key takeaway
In NZ government procurement, the Test Manager who reads the GETS listing before the commercial team reads the budget is the one who controls the engagement — everyone else is reacting to obligations they didn't know they'd accepted.
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.