stage 3 other materials evaluation

---
layout: raw-data.njk
title: "stage 3 other materials evaluation"
---

# Stage 3: Evaluation of Other Materials Relevance

## Date and Agent
- Date: 2025-11-19
- Agent: Claude (general-purpose agent)

## Objective

Assess whether materials in OtherMaterialsToEvaluate/ are essential for identification management practice and should be integrated into restructured identification standards. **Priority focus**: Determine the relationship between the Electronic Identity Verification Act (EIVA) and identification standards, specifically whether conformance with standards satisfies EIVA obligations.

## Methodology

### Tools and Approaches Used

1. **EIVA Analysis**:
   - Reviewed nz-eiva-71-en-chunked.json (1,067 chunks) for scope and requirements
   - Reviewed nz-eivr-64-en-chunked.json for regulations
   - Used MCP `semantic_search` for "electronic identity verification act EIVA identity credential verification requirements"
   - Used MCP `run_cypher_query` to find all EIVA references in identification standards
   - Examined DISTF Act section 16 relationship with EIVA

2. **Biometrics Analysis**:
   - Read Biometric Processing Privacy Code 2025 (comprehensive 13-rule code)
   - Reviewed sample biometrics guidance files from Privacy Commissioner
   - Used MCP `semantic_search` for "biometric authentication fingerprint facial recognition privacy"
   - Examined Authentication Assurance Standard biometrics controls

3. **Cybersecurity Standards Analysis**:
   - Read NCSC Multi-factor Authentication standard (representative sample)
   - Reviewed directory of 10 minimum cybersecurity standards
   - Used MCP `semantic_search` for "cybersecurity multi-factor authentication patching security controls"
   - Compared with Authentication Assurance Standard requirements

4. **Content Design Guidance Analysis**:
   - Read Plain Language guidance (Plain Language Act 2022 requirements)
   - Read Tone and Voice guidance (active voice, direct address)
   - Reviewed directory of 40+ content design documents
   - Compared with Stage 2 findings on passive voice and structure issues

5. **Integration Options Framework**:
   For each material set, evaluated against criteria:
   - Can user demonstrate conformance without this material?
   - Does this material fill gaps in current standards?
   - Would integration improve or complicate restructured materials?
   - Is this material stable or frequently updated?
   - Does it conflict with four core standards constraint?

## Key Findings

### PRIORITY: Electronic Identity Verification Act (EIVA) Evaluation

#### Legislative Framework Analysis

**Scope and Purpose**:
The Electronic Identity Verification Act 2012 (EIVA) establishes a **specific electronic identity credential service** administered by the Department of Internal Affairs (DIA). EIVA creates:

- **Electronic Identity Verification Service**: A DIA-operated service providing electronic identity credentials
- **Electronic identity credential**: A digital record containing "authenticated core identity information" (full name, sex, date of birth, place of birth) assigned a unique code by the Service
- **Participating agencies**: Government agencies declared by regulation that may use the Service to verify identity electronically
- **Core identity information authentication**: DIA authenticates identity information and issues credentials

**Key EIVA Requirements**:
1. Individuals may apply for electronic identity credentials through the Service
2. Participating agencies may verify identity by electronic means using these credentials
3. Credentials must be maintained, can be suspended/cancelled/revoked
4. Status changes must be notified to participating agencies (Section 20)
5. Privacy and access controls for credential information
6. Offences for fraudulent applications or misuse

**EIVA Does NOT**:
- Mandate use of identification standards
- Reference identification management standards
- Require conformance assessment
- Set authentication, information assurance, binding, or federation requirements
- Establish levels of assurance framework
- Cover identification management beyond the specific Service

#### Relationship to Identification Standards

**Direct References Found**:

The identification standards **reference EIVA only once** in the entire corpus:

"Section 20: Effect of change in status of electronic identity credential — Electronic Identity Verification Act 2021 — NZ Legislation" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5-section16-para7-ex1-exl2))

This appears in the Federation Assurance Standard implementation guidance as an **example** of credential status notification requirements, not as a normative requirement.

**No Other Integration**: The MCP server search returned:
- 10 total nodes mentioning "Electronic Identity Verification Act"
- 3 in Privacy Act 2020 (information matching provisions)
- 4 in DISTF Act (section 16 stating DISTF "does not limit or affect" EIVA)
- 3 in Federation implementation guidance (single example reference)
- **0 in the four core standards**
- **0 establishing any dependency or conformance requirement**

**EIVA Does Not Reference Standards**: Examination of EIVA's 1,067 content chunks found:
- No mentions of "identification management"
- No mentions of "identification standards"
- No mentions of "Department of Internal Affairs" as standards authority
- No mentions of "DIA" in standards context
- No mentions of assurance levels, conformance assessment, or identification management framework
- EIVA defines its own authentication process independently of identification standards

**DISTF Act Explicitly Separates EIVA and Standards**:

The Digital Identity Services Trust Framework Act 2023, section 16 states: "Relationship with Electronic Identity Verification Act 2012 and Identity Information Confirmation Act 2012: Nothing in this Act limits or otherwise affects the Electronic Identity Verification Act 2012 or the Identity Information Confirmation Act 2012." ([DocRef](https://docref.digital.govt.nz/nz/distf/14/en/#P2-s16))

This confirms EIVA operates **independently** of the DISTF framework, which **does** mandate use of identification standards.

#### Answer to Tom's Critical Question

**QUESTION**: "Should we add the electronic identity verification act and regulations? They only seem to be referenced in the federation standard. Also, the identify verification act and regs don't seem to acknowledge the existence of the identification standards at all. Whether conformance with standards satisfies EIVA obligations?"

**ANSWER**:

**No, do not integrate EIVA into identification standards. The relationship is minimal and unidirectional.**

**Evidence**:

1. **EIVA and standards address different concerns**:
   - **EIVA**: Establishes a **specific government service** (Electronic Identity Verification Service) for issuing and verifying electronic credentials
   - **Identification standards**: Establish **general requirements** for any party conducting identification management, regardless of technology or service

2. **No conformance relationship exists**:
   - EIVA does not require conformance with identification standards
   - Conforming with identification standards does not satisfy EIVA obligations
   - EIVA obligations apply only to: (a) the chief executive of DIA administering the Service, and (b) participating agencies using the Service
   - Most entities subject to identification standards will never use EIVA Service

3. **EIVA scope is narrow**:
   - Applies only to the specific DIA-operated Service
   - Most identity verification in NZ does not use this Service
   - DISTF framework (which does mandate identification standards) explicitly does not affect EIVA (section 16)

4. **Standards are broader**:
   - Identification standards apply to authentication, binding, information assurance, and federation **regardless** of technology
   - Standards apply to physical credentials (driver's licences, passports) and in-person verification
   - Standards apply to private sector, cross-border, and non-government scenarios
   - EIVA Service is just one possible implementation approach among many

5. **Tom's observation confirmed**:
   - "They only seem to be referenced in the federation standard" — Correct, one example reference
   - "The identify verification act and regs don't seem to acknowledge the existence of the identification standards at all" — Correct, zero references found

**Conclusion**: EIVA is a **parallel system** for a specific service, not a foundational legal requirement for identification management. It should remain external to identification standards with, at most, a brief explanatory note that EIVA Service exists as one possible implementation approach.

#### Integration Recommendation

**DO NOT INTEGRATE** EIVA into restructured identification standards.

**RATIONALE**:
1. **Not essential for practice**: Users can implement identification management without EIVA Service (most will)
2. **No dependency**: Standards do not depend on EIVA; EIVA does not depend on standards
3. **Different audiences**: EIVA applies to DIA and participating agencies only
4. **Scope mismatch**: EIVA is specific service; standards are general framework
5. **Would confuse**: Integration would wrongly imply EIVA is required for conformance

**RECOMMENDED APPROACH**:
- **Brief mention** in Phase 2 restructured materials: "The Electronic Identity Verification Act 2012 establishes a specific government service for electronic identity credentials. This is one possible implementation approach. The identification standards are technology-neutral and apply regardless of whether EIVA Service is used."
- **Do not extract content** from EIVA
- **Do not require familiarity** with EIVA as prerequisite
- **External reference only**: Link to legislation for those interested

### Privacy Commissioner's Biometric Processing Privacy Code Evaluation

#### Scope and Coverage

**Legislative Authority**:
The Biometric Processing Privacy Code 2025 is made under section 32 of the Privacy Act 2020 by the Privacy Commissioner. It came into force 3 November 2025 for new biometric processing (existing systems have until 3 August 2026).

**Comprehensive Regulatory Framework**:
The Code establishes **13 detailed rules** for biometric processing:

1. **Rule 1**: Purpose of collection (lawful purpose, necessity, proportionality, privacy safeguards)
2. **Rule 2**: Source of biometric sample (directly from individual where practicable)
3. **Rule 3**: Collection of information from individual (notice requirements, consent)
4. **Rule 4**: Manner of collection (lawful, not unreasonably intrusive)
5. **Rule 5**: Storage and security (appropriate safeguards)
6. **Rule 6**: Access to biometric information (individual access rights)
7. **Rule 7**: Correction of biometric information (individual correction rights)
8. **Rule 8**: Accuracy before use or disclosure (accuracy checking requirements)
9. **Rule 9**: Retention of biometric information (retention limits)
10. **Rule 10**: Limits on use (purpose limitation)
11. **Rule 11**: Limits on disclosure (disclosure restrictions)
12. **Rule 12**: Disclosure outside New Zealand (overseas transfer requirements)
13. **Rule 13**: Unique identifiers (restrictions on unique identifier use)

**Definitions Cover Identification Use Cases**:
- **Biometric identification**: Automated recognition for **identifying** an individual by comparing characteristics
- **Biometric verification**: Automated one-to-one verification of claimed identity
- **Biometric categorisation**: Analysing characteristics to infer demographics, emotion, mental state, etc.

**Applies to All Biometric Systems**: The Code covers any "technological system" used for biometric processing, including:
- Facial recognition for identity verification
- Fingerprint authentication
- Iris/retina scanning
- Voice recognition
- Behavioral biometrics (gait, keystroke)
- Any combination thereof

#### Overlap with Identification Standards

**Authentication Assurance Standard Coverage**:

The MCP search for "biometric authentication fingerprint facial recognition privacy" returned 15 results, showing current identification standards **do address biometrics**:

**Controls in Authentication Assurance Standard**:
- **AA9.04**: Spoofing of biometric challenges - requires appropriate measures to detect spoofing attempts (recordings, masks, makeup, prosthetics) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart2-section34-para1))
- **AA10.01**: Reduce false positives - guidance on managing probabilistic nature of biometric comparison, false positive/negative rates, operator training ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part3-subpart3-para1))
- **AA10.02**: Using additional factor with biometrics - combining biometric with different factor for higher assurance ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart3-section38-para1))

**Authenticator Types Guidance**:
- **Part 5**: "Something you are" - biometric recognition detailed guidance
- Describes physical (face, fingerprint, iris), behavioral (voice, keystroke, gait), chemical (DNA, body chemistry) characteristics
- Discusses local vs remote recognition systems
- Notes biometric recognition is "most controversial authenticator types"
- Addresses spoofing, degeneration, liveness checking, revocability concerns
- "Biometric characteristics are usually un-revocable if compromised (faces cannot be changed like passwords)" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authenticator-types/2021/en/#part5-det12-para9))

**Implementation Guidance**:
- "Biometric characteristics do not constitute secrets. They can be obtained online or by recording someone... with or without their knowledge" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part3-subpart2-section25-para1))
- Presentation attack detection (PAD) technologies discussed
- Rate limiting on failed authentication attempts
- False positive management for different biometric types

**Stage 2 Annotations**: Tom noted "importance of biometrics" multiple times:
- "Note importance of biometrics" (Authentication Standard, part5-subpart2-section30)
- "Note importance of biometrics in terms of adding other biometric guidance materials" (Authentication Standard, part5-subpart3-title)

#### Gaps Identified

**What Identification Standards Cover Well**:
- Technical effectiveness of biometric authentication (false positive rates, spoofing detection)
- Appropriate use of biometrics for different assurance levels
- Combination with other factors
- Authentication process controls

**What Privacy Code Adds That Standards Lack**:

1. **Privacy-specific requirements**:
   - **Necessity and proportionality assessment** (Rule 1) - Standards don't require justification for biometric choice
   - **Individual consent requirements** (Rule 3) - Standards assume consent, don't specify how to obtain
   - **Notice requirements** - What individuals must be told about biometric processing
   - **Individual rights** (access, correction) - Standards don't address individual rights framework
   - **Retention limits** (Rule 9) - Standards don't specify how long biometric templates can be kept
   - **Purpose limitation** (Rule 10) - Standards don't restrict use to original purpose
   - **Disclosure restrictions** (Rule 11) - Standards don't address sharing biometric information

2. **Privacy safeguards framework**:
   - Risk assessment methodology for privacy implications
   - Accessibility considerations for individuals with disabilities
   - Protections against adverse actions based on biometric results
   - Special protections for biometric categorisation (inferring characteristics)

3. **Compliance obligations**:
   - Privacy Code is **mandatory law** for biometric processing in NZ
   - Identification standards are **voluntary** unless mandated by specific framework (e.g., DISTF)
   - Non-compliance with Privacy Code can result in Privacy Commissioner complaints, investigations, enforcement

**Critical Gap**: The identification standards treat biometric authentication as a **technical control** without addressing the **legal and ethical privacy requirements** that govern biometric processing in New Zealand.

#### Integration Recommendation

**PARTIAL INTEGRATION** - Augment identification standards with privacy requirements for biometric systems.

**RATIONALE**:
1. **Essential for practice**: Any entity implementing biometric authentication **must** comply with Privacy Code - it's law
2. **Fills critical gap**: Standards address technical effectiveness but not legal compliance
3. **User protection**: Biometric processing has significant privacy implications that identification practitioners must understand
4. **Conformance relevance**: Conformance assessment should verify privacy compliance for biometric systems
5. **Tom's explicit interest**: Stage 2 annotations flagged biometrics as important emerging area

**RECOMMENDED APPROACH**:

**For Phase 2 restructured materials**:

1. **In Authentication Assurance Standard guidance** (can be modified):
   - Add section: "Privacy Requirements for Biometric Authentication"
   - State clearly: "All biometric processing in New Zealand must comply with the Biometric Processing Privacy Code 2025"
   - Extract key requirements: necessity, proportionality, consent, notice, retention limits, purpose limitation
   - Link to Privacy Commissioner resources and full Code
   - Integrate privacy considerations into AA9 and AA10 guidance

2. **In Conformance guidance** (can be modified):
   - Add biometric-specific conformance checkpoint: "Biometric systems must demonstrate compliance with Privacy Act 2020 and Biometric Processing Privacy Code 2025"
   - Reference Privacy Commissioner's enforcement role
   - Note that technical assurance (AA9, AA10) is necessary but not sufficient for biometric conformance

3. **Do not modify core Authentication Assurance Standard controls**: The technical controls (AA9.04, AA10.01, AA10.02) are correct and should not change. Augment with privacy requirements in guidance only.

4. **Cross-reference approach**: Rather than reproducing entire 13-rule Code, provide:
   - Summary of key privacy obligations
   - Explanation of how privacy requirements complement technical controls
   - Direct links to authoritative Privacy Commissioner resources
   - Statement that full Code compliance is mandatory

**IMPLEMENTATION**:
- **Essential content to extract**: Rules 1 (necessity/proportionality), 3 (consent/notice), 5 (security), 9 (retention), 10 (purpose limitation)
- **Format**: Brief summary of each rule + link to Privacy Commissioner guidance
- **Location**: Authentication Assurance implementation guide, Section on Objective 9 (biometric factors) and Objective 10 (biometric probability)
- **Estimated addition**: 2-3 pages of guidance content

### NCSC 10 Minimum Cybersecurity Standards Evaluation

#### Scope and Coverage

**Authoritative Security Framework**:
The National Cyber Security Centre (NCSC) 10 Minimum Cybersecurity Standards provide **mandatory minimum requirements** for New Zealand public service agencies. Standards cover:

1. Multi-factor Authentication (MFA)
2. Patching
3. Least Privilege
4. Assets and Their Importance
5. Data Recovery
6. Detect Unusual Behaviour
7. Security Awareness
8. Response Planning
9. Risk Management
10. Secure Configuration of Software

**Maturity Model Framework**:
Each standard defines requirements across 4 Cyber Security Capability Maturity Model (CS-CMM) levels:
- **CMM 1 Informal**: Basic/ad-hoc implementation
- **CMM 2 Planned and Tracked**: Minimum required level for most standards
- **CMM 3 Standardised**: Consistent enterprise-wide implementation
- **CMM 4 Quantitatively Controlled**: Measured and optimized

**Example - Multi-factor Authentication Standard**:
- **CMM 2 (minimum)**: MFA for business-critical and externally facing systems; privileged users must have MFA; unsuccessful MFA logs retained and reviewed
- **CMM 3**: MFA for external systems, business-critical systems, and core network access; MFA cannot be bypassed except "break glass" scenarios
- **CMM 4**: MFA for all entities across all systems; all successful and unsuccessful MFA logs retained and reviewed

**Tom's Observation**: "Linking out to privacy and security standards without specificity is not helpful" (TomNotesManualReview.md, line 5)

#### Overlap with Identification Standards

**MCP Search Results**: "cybersecurity multi-factor authentication patching security controls" returned 15 results:

**Current References in Standards**:
- Authentication Assurance Standard mentions multi-factor authentication extensively
- Control AA11 series addresses Authenticator lifecycle (establishment, activation, storage, usage, renewal, suspension, revocation)
- Implementation guidance discusses two-factor authentication benefits
- General statement: "Authentication assurance controls are designed to reduce the likelihood of" various security outcomes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part1-para4))

**Authenticator Types Guidance**:
- "Multi-factor authentication increases the likelihood of being able to mitigate against a wide number of threats to the authentication process" ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authenticator-types/2021/en/#part6-para4))
- Explains when multiple factors of same type don't increase assurance
- Guidance on contiguous challenging of multiple factors

**What Standards Cover**:
- **MFA concept and benefits**: Well explained in Authenticator Types guidance
- **When to use MFA**: Specified by level of assurance (LoA2, LoA3)
- **Factor combination principles**: Knowledge + possession, biometric + other factor
- **Authentication threats**: Guessing, theft, sharing, spoofing addressed

#### Gaps Identified

**What NCSC Standards Add That Identification Standards Lack**:

1. **Mandatory implementation requirements**:
   - NCSC specifies **which systems** must have MFA (business-critical, externally facing, core network)
   - NCSC specifies **which users** must have MFA (privileged users at minimum)
   - NCSC requires **logging and monitoring** of authentication attempts
   - NCSC prohibits **MFA bypass** except managed "break glass" scenarios

2. **Broader security context**:
   - **Patching**: Keeping authentication systems up to date - not addressed in identification standards
   - **Least Privilege**: Limiting access to authentication systems - not addressed
   - **Asset Classification**: Understanding which systems need what authentication level - mentioned in risk assessment but not cybersecurity context
   - **Detect Unusual Behaviour**: Anomaly detection in authentication patterns - touched on in AA3 but not comprehensively
   - **Response Planning**: What to do when authentication is compromised - not addressed
   - **Secure Configuration**: Hardening authentication systems - not addressed

3. **Operational security requirements**:
   - NCSC addresses **how to implement** authentication securely (system hardening, monitoring, incident response)
   - Identification standards address **what authentication assurance to achieve** (levels, factors, controls)
   - Different perspectives: operational security vs assurance framework

4. **Compliance obligations**:
   - NCSC standards are **mandatory** for NZ public service agencies
   - Identification standards are **voluntary** unless mandated by specific framework
   - Public service agencies must meet **both** NCSC and identification standards (where DISTF applies)

**Relationship Analysis**:

**Identification Standards are about "WHAT"**:
- What level of assurance is needed
- What factors to use
- What controls to apply
- What threats to mitigate

**NCSC Standards are about "HOW"**:
- How to implement securely
- How to configure systems
- How to monitor and respond
- How to maintain security posture

**Complementary but distinct domains**: Identification standards establish **assurance requirements**; NCSC standards establish **operational security requirements**.

#### Integration Recommendation

**REFERENCE, DON'T INTEGRATE** - Link to NCSC standards as complementary security requirements.

**RATIONALE**:
1. **Different domains**: Identification = assurance framework; NCSC = operational security
2. **Different audiences**: Identification standards apply to any party; NCSC standards apply to public service agencies only
3. **Different purposes**: Standards for identification management conformance vs standards for cyber security baseline
4. **Duplication risk**: NCSC standards update regularly (MFA standard updated 30 October 2025); integrating would create maintenance burden and version conflicts
5. **Authority separation**: NCSC is cybersecurity authority; DIA is identification authority - maintain clear boundaries

**RECOMMENDED APPROACH**:

**For Phase 2 restructured materials**:

1. **In implementation guidance** (can be modified), add section: "Cybersecurity Requirements for Authentication Systems"
   - State clearly: "Implementing secure authentication systems requires both identification assurance controls (this standard) and cybersecurity controls"
   - For public service agencies: "NZ public service agencies must also comply with NCSC 10 Minimum Cybersecurity Standards"
   - Link to NCSC standards: https://www.ncsc.govt.nz/protect-your-organisation/minimum-cyber-security-standards/
   - Specify relevant NCSC standards: MFA, Patching, Least Privilege, Secure Configuration, Detect Unusual Behaviour

2. **Be specific about relationship** (addressing Tom's concern):
   - "NCSC MFA standard specifies WHICH systems must have MFA and WHO must use it"
   - "Identification standards specify WHAT TYPE of MFA provides what level of assurance"
   - "Both must be met: NCSC standards ensure secure implementation; identification standards ensure appropriate assurance"

3. **In Authentication Assurance Standard guidance** (can be modified):
   - Add note to control AA11 (Authenticator lifecycle): "Secure authenticator lifecycle management requires compliance with NCSC standards for patching, secure configuration, and least privilege access to authentication systems"
   - Add note to control AA3 (Anomalous behavior detection): "See also NCSC standard 'Detect Unusual Behaviour' for comprehensive anomaly detection requirements"

4. **Do not reproduce NCSC content**: NCSC standards are well-maintained, authoritative, and regularly updated. Link, don't duplicate.

**IMPLEMENTATION**:
- **Format**: Brief explanatory section + specific cross-references to relevant NCSC standards
- **Location**: Authentication Assurance implementation guide, new section "Operational Security Requirements"
- **Estimated addition**: 1 page of guidance with links

**BENEFIT**: Addresses Tom's concern about "linking out without specificity" by explaining exactly WHICH NCSC standards apply, WHY they complement identification standards, and HOW they relate to authentication assurance.

### Digital.govt.nz Content Design Guidance Evaluation

#### Relevance Assessment

**Not Content to Integrate - Authoring Guidelines for Phase 2**

The 40+ content design documents from digital.govt.nz are **methodology guidance for creating content**, not substantive content to include in identification standards.

**Key Guidance Documents Reviewed**:

1. **Plain Language** (www.digital.govt.nz_standards-and-guidance_design-and-ux_content-design-guidance_writing-style_plain-language.md):
   - **Plain Language Act 2022**: Mandatory for public service agencies (effective 21 April 2023)
   - Requires documents to be "appropriate to the audience" and "clear, concise and well organised"
   - Only 16% of NZ adults have high literacy levels - plain language improves accessibility
   - Provides tools and testing resources

2. **Tone and Voice** (www.digital.govt.nz_standards-and-guidance_design-and-ux_content-design-guidance_writing-style_tone-and-voice.md):
   - Writing must be: straightforward, human, authoritative, impartial
   - **"Use the active voice, where possible"** - directly addresses Stage 2 passive voice finding
   - **"Use 'you' and 'your' when talking to the reader"** - directly addresses Stage 2 direct address finding
   - Examples: "Take a copy of your [document]" not "provide supporting documents"

3. **Other Guidance Topics** (40+ documents):
   - Readability, numbers, words to avoid
   - Page structure, headings, lists, formatting
   - Findable content, SEO, links
   - Inclusive language (gender, disability, age, Pacific peoples, te reo Māori)
   - Grammar and punctuation
   - Research, planning, maintenance processes
   - Working with subject matter experts
   - Content audit and tracking templates

#### Alignment with Stage 2 Issues

**Digital.govt.nz Guidance DIRECTLY ADDRESSES Identified Problems**:

**Stage 2 Theme A: Passive Voice Pervades Guidance**
- **Content design solution**: "Use the active voice, where possible" (Tone and Voice guidance)
- **Content design solution**: "Use 'you' and 'your' when talking to the reader" (Tone and Voice guidance)
- **Perfect alignment**: Stage 2 identified passive voice as systemic problem; digital.govt.nz provides the solution methodology

**Stage 2 Theme B: Content Fragmentation and "Tucked Away" Information**
- **Content design solution**: Page structure guidance on information hierarchy
- **Content design solution**: Headings and subheadings guidance on scanability
- **Content design solution**: Findable content guidance on surfacing important information

**Stage 2 Theme C: Standards-Guidance Separation Creates Friction**
- **Content design solution**: Content structure guidance on organizing complex information
- **Content design solution**: Guidance on when to combine vs separate content

**Stage 2 Theme D: Terminology Authority and Function Unclear**
- **Content design solution**: Plain language guidance on appropriate audience language
- **Content design solution**: "Words to avoid and specialist words" guidance
- **Content design solution**: Writing for specialists vs general public

**Stage 2 Theme F: Conformance Should Be Central**
- **Content design solution**: User-centered content design - organize by user goals
- **Content design solution**: Page structure - put most important information first

**Stage 2 Theme G: Structure and Formatting Issues**
- **Content design solution**: Headings and subheadings best practices
- **Content design solution**: Lists and formatting for scanability
- **Content design solution**: Links and cross-references

**Stage 2 Pattern 4: No Clear User Journey**
- **Content design solution**: Content design process guidance
- **Content design solution**: User research and user needs methodology

**Stage 2 Good Practice J**: Tom praised active voice sections
- **Content design validation**: Digital.govt.nz confirms active voice is government standard

#### Integration Recommendation

**DO NOT INTEGRATE CONTENT - USE AS PHASE 2 AUTHORING GUIDE**

**RATIONALE**:
1. **Process guidance, not substantive content**: These are "how to write" instructions, not "what to write" material
2. **Already government standard**: Digital.govt.nz is the authoritative source - no need to reproduce
3. **Phase 2 methodology**: These documents describe exactly the approach Phase 2 should take
4. **Addresses Stage 2 findings**: Content design principles solve identified problems
5. **Plain Language Act compliance**: Phase 2 must comply with mandatory Plain Language Act 2022

**RECOMMENDED APPROACH**:

**Use digital.govt.nz guidance as METHODOLOGY for Phase 2 content creation (Stage 11)**:

1. **Active voice throughout**: Apply Tone and Voice guidance systematically
   - Rewrite guidance materials (not core standards) in active voice
   - Use "you" and "your" to address reader directly
   - Change passive constructions: "is performed" → "you perform"

2. **Plain language**: Apply Plain Language guidance
   - Clear, concise, well-organized language
   - Appropriate to audience (technical practitioners, assessors, auditors)
   - Use specialist terms where necessary but explain them

3. **Information architecture**: Apply Page Structure and Findable Content guidance
   - Surface important information (conformance process, threshold considerations)
   - Eliminate detail expanders that hide content
   - Improve heading hierarchy for scanability

4. **User-centered organization**: Apply Content Design Process guidance
   - Organize by user goals (seeking conformance, understanding requirements)
   - Create clear entry points for different audiences
   - Make conformance process prominent

5. **Consistent formatting**: Apply Formatting, Lists, Headings guidance
   - Consistent heading levels
   - Effective use of lists
   - Clear cross-references

**IMPLEMENTATION IN PHASE 2**:

**Stage 8: Markdown Style Familiarization**:
- Study existing markdown files AND digital.govt.nz guidance
- Document style requirements including plain language principles

**Stage 11: Content Synthesis and Writing**:
- Use digital.govt.nz as writing guide for all new content
- Apply Active Voice guidance to all guidance materials (not core standards)
- Apply Plain Language principles throughout
- Use Tone and Voice guidance for direct, clear language
- Reference specific guidance documents as needed during writing

**Stage 12: Verification and Quality Assurance**:
- Verify active voice usage in rewritten guidance
- Verify plain language compliance
- Check against readability testing tools recommended by digital.govt.nz
- Ensure tone is "straightforward, human, authoritative, impartial"

**Document in Phase 1 Stage 6 Recommendations**:
- Cite digital.govt.nz content design guidance as methodology for Phase 2
- List specific guidance documents to use for each writing task
- Include in "Content Design Principles" section of recommendations

**NO CONTENT EXTRACTION NEEDED**: Link to digital.govt.nz resources in Introduction or "About This Resource" section of restructured standards, stating: "This resource follows New Zealand government content design guidance for plain language, active voice, and user-centered structure. See digital.govt.nz content design guidance for more information."

## Supporting Evidence

### Evidence of EIVA's Limited Relationship with Standards

**Zero Normative References**: MCP Cypher query for EIVA mentions returned only:
- Example citation in Federation guidance (credential status notification)
- Legal relationship statement in DISTF Act (DISTF does not affect EIVA)
- Privacy Act information matching provisions

**No Standards References in EIVA**: Review of 1,067 EIVA content chunks found zero mentions of identification management standards framework.

**DISTF Distinguishes EIVA from Standards**: Section 16 explicitly states DISTF does not limit or affect EIVA ([DocRef](https://docref.digital.govt.nz/nz/distf/14/en/#P2-s16)), confirming these are separate legal regimes.

**Tom's Observation Confirmed**: "They only seem to be referenced in the federation standard" - correct. "The identify verification act and regs don't seem to acknowledge the existence of the identification standards at all" - correct.

### Evidence of Biometrics Gap in Standards

**Stage 2 Annotations**:
- "Note importance of biometrics" (Authentication Standard, part5-subpart2-section30)
- "Note importance of biometrics in terms of adding other biometric guidance materials" (Authentication Standard, part5-subpart3-title)

**Technical Controls Present**: Standards address false positives, spoofing, factor combination

**Privacy Requirements Absent**: Standards do not address:
- Necessity and proportionality assessment
- Consent and notice requirements
- Retention limits
- Purpose limitation
- Individual rights (access, correction)
- Disclosure restrictions

**Privacy Code is Mandatory Law**: Effective 3 November 2025, applies to all biometric processing in NZ

**Gap Impact**: Users implementing biometric authentication per identification standards could still violate Privacy Code without additional privacy guidance.

### Evidence of NCSC Standards Complementarity

**Different Domains Confirmed**:
- Identification standards: "Authenticators using biometric factors offer more effective mitigation against sharing" (technical assurance) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart1-para3))
- NCSC MFA standard: "MFA is required to be used by privileged users and cannot be bypassed unless within a managed 'break glass' scenario" (operational security)

**Tom's Concern**: "Linking out to privacy and security standards without specificity is not helpful"

**Solution**: Be specific about WHICH NCSC standards, WHY they're relevant, HOW they complement identification standards

### Evidence of Content Design Guidance Alignment with Stage 2

**Perfect Match**:
- Stage 2 found: "Passive voice pervades guidance materials" (Theme A)
- Digital.govt.nz states: "Use the active voice, where possible" (Tone and Voice)
- Stage 2 found: "Content fragmentation and 'tucked away' information" (Theme B)
- Digital.govt.nz provides: Page structure, findable content, information hierarchy guidance
- Stage 2 found: "Conformance should be central, not peripheral" (Theme F)
- Digital.govt.nz principle: User-centered design - organize by user goals

**Plain Language Act 2022**: Makes plain language mandatory for public service agencies (identification standards are government resource)

**Government Standard**: Digital.govt.nz represents official government approach to content design

## Cross-Material Integration Analysis

### Complementary Relationships Identified

**Biometrics + Privacy + Security**:
- **Identification standards**: Technical assurance requirements (AA9, AA10)
- **Privacy Code**: Legal privacy requirements (necessity, consent, retention, purpose limitation)
- **NCSC standards**: Operational security requirements (MFA implementation, system hardening, monitoring)
- **Relationship**: All three required for compliant biometric authentication in NZ
- **Integration approach**: Standards remain technical; augment with privacy and security cross-references

**Content Design + Plain Language Act**:
- **Plain Language Act 2022**: Mandatory legal requirement for public service content
- **Digital.govt.nz guidance**: Methodology for compliance
- **Identification standards restructuring**: Must comply with both
- **Relationship**: Digital.govt.nz provides the "how" for legal requirement
- **Integration approach**: Use as authoring methodology in Phase 2

### Conflicts or Tensions Identified

**No Conflicts Found**: All evaluated materials are complementary rather than conflicting:

- **EIVA vs Standards**: Separate domains, no conflict
- **Privacy Code vs Standards**: Privacy requirements augment technical controls, don't contradict
- **NCSC vs Standards**: Operational security complements assurance framework, doesn't conflict
- **Content Design vs Standards**: Writing methodology, not substantive requirement

**Alignment with Four Core Standards Constraint**: None of the evaluated materials require modifying core standards text:
- Biometrics privacy requirements: Add to implementation guidance, not core controls
- NCSC security requirements: Add references in implementation guidance
- Content design principles: Apply to guidance materials, not core standards
- EIVA: No integration needed

## Essential vs. Supplementary Classification

### ESSENTIAL for Identification Management Practice

**1. Privacy Commissioner's Biometric Processing Privacy Code 2025** (for biometric authentication):
- **Why essential**: Mandatory law for biometric processing in NZ
- **Who needs it**: Any entity implementing biometric authentication
- **Integration level**: Partial - augment standards with privacy requirements
- **Priority**: HIGH - fills critical gap

**2. Digital.govt.nz Content Design Guidance** (for Phase 2 authoring):
- **Why essential**: Provides methodology to fix Stage 2 issues; Plain Language Act compliance required
- **Who needs it**: Phase 2 content creators (not end users)
- **Integration level**: Use as authoring guide, don't integrate content
- **Priority**: HIGH - methodology for Phase 2

### SUPPLEMENTARY but Recommended

**3. NCSC 10 Minimum Cybersecurity Standards** (for authentication system implementation):
- **Why supplementary**: Mandatory for public service agencies but not all identification practitioners
- **Who needs it**: Public service agencies, security-conscious implementers
- **Integration level**: Reference with specific explanation of relationship
- **Priority**: MEDIUM - addresses Tom's concern about "linking without specificity"

### NOT ESSENTIAL for Identification Management

**4. Electronic Identity Verification Act 2012**:
- **Why not essential**: Applies only to specific DIA service, not general identification management
- **Who might use it**: Participating agencies in EIVA Service (small subset)
- **Integration level**: Brief mention only, external reference
- **Priority**: LOW - minimal relevance to most users

## Integration Strategy by Material

### 1. Privacy Commissioner's Biometric Processing Privacy Code - AUGMENT STANDARDS

**Location**: Authentication Assurance Standard implementation guidance

**Approach**:
- New section: "Privacy Requirements for Biometric Authentication"
- Extract 5 key rules: necessity/proportionality, consent/notice, security, retention, purpose limitation
- Each rule: 1 paragraph summary + link to Privacy Commissioner guidance
- Integrate with existing AA9 (spoofing) and AA10 (probability) guidance
- Statement: "All biometric processing must comply with Biometric Processing Privacy Code 2025"

**Format**: 2-3 pages of guidance content with citations and links

**Benefit**: Ensures users understand both technical assurance AND legal privacy requirements

### 2. Digital.govt.nz Content Design Guidance - USE AS AUTHORING METHODOLOGY

**Location**: Phase 2 workflow (Stages 8, 11, 12)

**Approach**:
- Stage 8: Study content design guidance alongside markdown examples
- Stage 11: Apply active voice, plain language, tone/voice, structure principles during writing
- Stage 12: Verify compliance with content design principles
- Brief mention in restructured standards: "This resource follows NZ government content design guidance"

**Format**: Methodology reference, not content integration

**Benefit**: Addresses Stage 2 systematic issues (passive voice, fragmentation, findability) using government-standard methodology

### 3. NCSC 10 Minimum Cybersecurity Standards - REFERENCE WITH SPECIFICITY

**Location**: Authentication Assurance Standard implementation guidance

**Approach**:
- New section: "Cybersecurity Requirements for Authentication Systems"
- Explain relationship: "Identification standards (assurance) + NCSC standards (security) = complete implementation"
- List relevant NCSC standards: MFA, Patching, Least Privilege, Secure Configuration, Detect Unusual Behaviour
- Be specific about what each adds: "NCSC MFA standard specifies WHICH systems; identification standards specify WHAT TYPE of MFA"
- Link to NCSC website

**Format**: 1 page of guidance with specific cross-references

**Benefit**: Addresses Tom's concern about "linking without specificity" by explaining exactly what NCSC adds and why

### 4. Electronic Identity Verification Act 2012 - BRIEF MENTION ONLY

**Location**: Federation Assurance Standard implementation guidance (existing example reference can remain)

**Approach**:
- Brief explanatory note: "EIVA establishes a specific government electronic identity credential service. This is one possible implementation approach. Identification standards are technology-neutral and apply regardless of EIVA Service use."
- Link to EIVA legislation for reference
- No content extraction

**Format**: 1 paragraph note

**Benefit**: Clarifies EIVA's limited relationship without over-integrating irrelevant material

## Implications for Phase 2 Structure

### Content Additions Needed

**Authentication Assurance Implementation Guide** will grow by approximately 3-4 pages:
- 2-3 pages: Biometrics privacy requirements
- 1 page: Cybersecurity requirements cross-reference
- Fits within restructured guidance materials

**No Core Standards Changes**: Four core standards remain unchanged in substance

### Methodological Implications

**Phase 2 Stage 8 (Markdown Style)**: Must include content design principles alongside markdown syntax

**Phase 2 Stage 11 (Writing)**: Must apply:
- Active voice systematically (from digital.govt.nz)
- Plain language principles (Plain Language Act compliance)
- User-centered organization (from digital.govt.nz)
- Privacy Code requirements (for biometric sections)

**Phase 2 Stage 12 (Verification)**: Must verify:
- Active voice conversion complete in guidance
- Plain language compliance
- Privacy Code integration for biometrics
- NCSC cross-references clear and specific

### Stakeholder Review Considerations

**Adele (Usability Testing)**:
- Test whether privacy requirements for biometrics are understandable to implementers
- Test whether NCSC cross-references clarify rather than confuse
- Test whether active voice and plain language improve comprehension

**Joanne (Conformance/Terminology)**:
- Validate biometrics privacy requirements are accurate and complete
- Confirm NCSC cross-references are appropriate for conformance context
- Verify privacy and security additions don't create conformance ambiguity

**Privacy Commissioner** (potential stakeholder):
- May want to review biometrics privacy section for accuracy
- Could provide additional implementation guidance resources

**NCSC** (potential stakeholder):
- May want to review cybersecurity cross-reference section
- Could confirm relationship explanation is accurate

## Decisions Made

### Decision 1: Do Not Integrate EIVA

**Decision**: EIVA will receive brief mention only, no content integration

**Rationale**:
- EIVA and identification standards are separate frameworks
- No conformance relationship exists
- EIVA applies to narrow set of users (DIA + participating agencies)
- Integration would wrongly imply EIVA is required for identification management

**Confidence**: HIGH - evidence is conclusive (zero substantive references, separate legal regimes, different purposes)

### Decision 2: Augment Standards with Biometrics Privacy Requirements

**Decision**: Extract 5 key Privacy Code rules and integrate into Authentication Assurance implementation guidance

**Rationale**:
- Privacy Code is mandatory law for biometric processing
- Current standards have critical gap (technical controls without privacy requirements)
- Tom flagged biometrics as important emerging area
- Essential for compliant implementation

**Confidence**: HIGH - Privacy Code is law, applies to identification management, fills real gap

### Decision 3: Use Content Design Guidance as Phase 2 Methodology

**Decision**: Apply digital.govt.nz guidance throughout Phase 2 writing, don't integrate content

**Rationale**:
- Guidance is "how to write" not "what to write"
- Perfectly addresses Stage 2 issues (passive voice, fragmentation, findability)
- Plain Language Act compliance required
- Government standard methodology

**Confidence**: HIGH - clear methodology application, addresses identified problems

### Decision 4: Cross-Reference NCSC Standards with Specificity

**Decision**: Add 1-page section explaining NCSC standards relationship, with specific cross-references

**Rationale**:
- Addresses Tom's concern about "linking without specificity"
- NCSC standards complement identification standards (security + assurance)
- Public service agencies need both
- Clarifies relationship without duplicating content

**Confidence**: MEDIUM-HIGH - adds value by clarifying relationship, risk of becoming outdated if NCSC standards change frequently

## Questions and Uncertainties

### Question 1: Privacy Commissioner Coordination

**Question**: Should we coordinate with Privacy Commissioner's office on biometrics privacy section?

**Uncertainty**: Whether Privacy Commissioner would want to review, endorse, or provide additional resources

**Resolution approach**: Stage 6 recommendations should identify Privacy Commissioner as potential stakeholder for Phase 2 content review

### Question 2: NCSC Coordination

**Question**: Should we coordinate with NCSC on cybersecurity cross-reference section?

**Uncertainty**: Whether NCSC would want to review relationship explanation, whether they update standards frequently enough to create version problems

**Resolution approach**: Stage 6 recommendations should consider NCSC coordination; monitor NCSC standard update frequency

### Question 3: Plain Language Act Interpretation

**Question**: What level of "plain language" is appropriate for technical identification standards?

**Uncertainty**: Standards serve specialist audience (technical implementers, assessors) - how to balance specialist terminology with plain language requirements?

**Resolution approach**: Digital.govt.nz provides guidance on writing for specialists; Stage 11 writing must balance technical precision with accessibility; Adele usability testing can validate

### Question 4: Biometrics Privacy Section Depth

**Question**: How much Privacy Code detail to include - full 13 rules or extract key 5-6?

**Uncertainty**: Risk of too much (overwhelming) vs too little (insufficient for compliance)

**Resolution approach**: Stage 6 should propose specific level of detail; consider user needs (awareness of requirements vs full compliance guide)

### Question 5: Content Design Methodology Documentation

**Question**: Should Phase 2 workflow document which digital.govt.nz guidance documents are used for each writing task?

**Uncertainty**: Level of detail needed in workflow documentation

**Resolution approach**: Stage 6 recommendations should list key content design resources for each Phase 2 stage

### Question 6: Update Maintenance for External References

**Question**: How to handle updates to external materials (Privacy Code rules, NCSC standards, digital.govt.nz guidance)?

**Uncertainty**: Whether restructured standards need version tracking or update monitoring for referenced materials

**Resolution approach**: Stage 13 (handover) should identify external dependencies and recommend periodic review schedule

## Next Steps for Stage 4

Based on Stage 3 evaluation of other materials, Stage 4 (Thematic Synthesis) should focus on:

### 1. Synthesize Stages 1-3 Findings

Integrate findings from:
- Stage 1: Document taxonomy, MCP server capabilities, initial semantic searches
- Stage 2: 7 major patterns across documents (passive voice, fragmentation, standards-guidance separation, terminology, DISTF relationship, conformance visibility, structure issues)
- Stage 3: 4 material sets evaluated (EIVA minimal relevance, biometrics essential augmentation, NCSC complementary reference, content design methodology)

### 2. Develop Integrated Recommendations

**Voice and Tone Theme**:
- Stage 2: Passive voice pervades (Theme A)
- Stage 3: Digital.govt.nz provides active voice methodology
- **Synthesis**: Systematic active voice conversion using government-standard methodology

**Biometrics Emerging Theme**:
- Stage 2: Tom's annotations note biometrics importance
- Stage 3: Privacy Code fills critical gap in standards
- **Synthesis**: Biometrics requires both technical assurance (existing AA9, AA10) and privacy compliance (augment with Privacy Code)

**Security Requirements Theme**:
- Stage 2: Tom notes "linking without specificity is not helpful"
- Stage 3: NCSC standards complement identification standards
- **Synthesis**: Add specific cross-references explaining security-assurance relationship

**Conformance Centrality Theme**:
- Stage 2: Conformance is "whole point" but "tucked away"
- Stage 3: Content design methodology for user-centered organization
- **Synthesis**: Restructure around conformance workflow using content design principles

### 3. Clarify Terminology Authority Approach

Stage 2 identified terminology authority as unclear; Stage 3 adds context:
- DIA publishes standards - can assert definitional authority
- Digital.govt.nz guidance on specialist terms
- Privacy Code and NCSC standards use consistent terminology
- **Synthesis needed**: How should terminology be authoritative yet accessible?

### 4. Refine Standards-Guidance Integration Strategy

Stage 2 identified separation as problematic; Stage 3 reinforces with:
- Content design methodology for organizing complex information
- Plain language principles for specialist audiences
- Examples from digital.govt.nz
- **Synthesis needed**: Specific approach to integrating standards and guidance with clear visual distinction

### 5. Develop Content Design Framework

Stage 3 identified digital.govt.nz as methodology; Stage 4 should detail:
- Which guidance documents for which Phase 2 tasks
- How to apply active voice, plain language, tone/voice systematically
- How to verify compliance with content design principles
- **Synthesis needed**: Concrete content design framework for Phase 2

### 6. Map External Dependencies

Stage 3 identified 3 external dependencies (Privacy Code, NCSC, digital.govt.nz); Stage 4 should:
- Document relationships and integration points
- Identify update maintenance requirements
- Plan stakeholder coordination (Privacy Commissioner, NCSC)
- **Synthesis needed**: External dependency management strategy

### 7. Evaluate DISTF-EIVA-Standards Triangle

Stage 1 and 2 noted DISTF mandates standards; Stage 3 clarified EIVA is separate; Stage 4 should:
- Synthesize relationship between three frameworks
- Clarify for users which applies when
- Address Tom's observation about DISTF being "only mandatory use"
- **Synthesis needed**: Clear explanation of legal framework relationships

### 8. Assess Audience Segmentation Needs

Stages 1-3 identified multiple audiences (credential providers, assessors, relying parties, policy makers); Stage 4 should:
- Synthesize audience needs across findings
- Consider how content design principles support multiple audiences
- Evaluate whether single structure or multiple pathways needed
- **Synthesis needed**: Audience segmentation strategy

### 9. Prioritize Improvements by Impact and Feasibility

Stage 2 identified "immediate wins" vs "complex restructuring"; Stage 3 adds resources; Stage 4 should:
- Prioritize based on user impact, implementation effort, dependencies
- Consider constraint on core standards text
- Identify Phase 2 critical path
- **Synthesis needed**: Prioritized improvement roadmap

### 10. Prepare for Stage 5 (AI Guidance Evaluation)

Stage 4 synthesis will inform Stage 5 evaluation against AI guidance; prepare by:
- Consolidating user needs and pain points
- Identifying areas where AI guidance might provide additional principles
- Noting questions about optimal structure and organization
- **Synthesis needed**: Questions for AI guidance evaluation

## Output for Stage 4

Create `/WorkingFolder/04_thematic_synthesis.md` with:
- Synthesis of Stages 1-3 findings by theme
- Integrated understanding of patterns, external materials, and opportunities
- Refined recommendations across voice, structure, content design, terminology, conformance, integration
- External dependency framework
- Audience segmentation strategy
- Prioritized improvement roadmap
- Preparation for Stage 5 AI guidance evaluation

This will provide comprehensive foundation for Stage 5 (evaluating against AI guidance) and Stage 6 (final recommendations and structure proposal).