Skip to main content

NL-CS Part 4: NL-CS Audit Instruction for Operational Processes

NL-CS Part 4: NL-CS Audit Instruction for Operational Processes

Download PDF (2.4 MB, 19 pages)Read the full text24 requirements
Cover page of the document, as printed
Document referenceNL-CS (part4)
VersionRC1.0
StatusRelease Candidate
Date25/10/2026
Document typeFITCEM Certification Scheme Audit Instruction for Operational Processes
Parent frameworkNL-SYS-01, NL-SYS-02, NL-SYS-03, NL-SYS-04, NL-SYS-05 NL-TL
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallet Solutions
Primary audienceScheme Owners, Evaluation Laboratories; CABs, EUDI Wallet providers
Secondary audienceEUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
How to read this page

This page summarises the document. Every statement points to the section and page of the authoritative PDF it comes from: click a reference such as §6.1, p. 10 to open that page. If this summary and the PDF differ, the PDF applies.

What this document is​

NI003 instructs the Certification Body on the audit of the product developer's operational processes that maintain the security of the certified wallet: version control, change management, update delivery and vulnerability management (Document control, p. 2). [NP001] section 6.1 (phase 4) refers to it as the audit instruction, and section 7 lists it as the instruction for the audit of developer operational processes (Document control, p. 2). Because a certificate of conformity says something about one version of the wallet and the product developer keeps it secure afterwards through its operational processes, this instruction states what the CB audits in those processes, how, and how findings feed the certificate (§1.1, p. 5).

Scope and object of certification​

  • [NP001] section 2.2 scopes the management system element of the scheme to the processes directly relevant to the security maintenance of the certified product; general information security management systems are not part of the certification decision (§1.1, p. 5).
  • In scope: the four processes of section 4 (version control, change management, update delivery, vulnerability management) (§1.2, p. 5); the continued validity of the functional certificate and of the assumptions and certificates the certification relies on (section 4.5) (§1.2, p. 5); the initial audit, the annual surveillance audits and the audit within recertification (§1.2, p. 5).
  • Out of scope: general information security management, software development lifecycle assurance, conformity with the Cyber Resilience Act as a whole ([NP001] section 2.2), and the evaluation tasks of [NI002] (§1.2, p. 5).
  • Criteria marked [proposed] are drafting proposals derived from the sources named and are not yet decided (Document control, p. 2).

Who it applies to​

  • Lead auditor (Certification Body): plans and leads the audit, decides on the findings, signs the audit report; competent per section 6 (§1.3, p. 5). Sends the product developer the audit plan (§5.1, p. 11).
  • Auditor (Certification Body): performs audit activities under the lead auditor (§1.3, p. 5); shall verify statements by records and, where the audit type requires, by observation or interview (§2, p. 6); shall have the competence required by [ISO/IEC 17065] for certification personnel, knowledge of the wallet and its threat model, and knowledge of secure software maintenance and vulnerability handling for mobile applications (§6, p. 13).
  • Auditee (Product developer): provides the process documentation and the records, and makes the process owners available (§1.3, p. 5); the criteria of section 4 are what the processes shall achieve (§4, p. 8).
  • Technical support (Evaluation Laboratory): may support the CB with technical questions on the evidence, under the CB's responsibility — marked "[Proposed; [NP001] section 3.2 assigns the audit to the CB and does not mention laboratory support.]" (§1.3, p. 5).
  • The CB issues the audit report and keeps the records for the period set by the Scheme Owner (§5.6, p. 12).

Contents​

  • Document control — document metadata table, introductory paragraph and version history table; starts p.2 (Contents, p. 4).
  • 1 Introduction — purpose, scope, involved roles, conventions; starts p.5 (§1, p. 5).
  • 2 Audit principles — evidence-based audit, independence, confidentiality; starts p.6 (§2, p. 6).
  • 3 Audit types and schedule — table of initial, surveillance, recertification and special audits; starts p.7 (§3, p. 7).
  • 4 Audit criteria — criteria VC, CM, UD, VM and CV with sources; starts p.8 (§4, p. 8).
  • 5 Audit procedure — planning, document review, sampling of records, interviews and observation, findings, audit report; starts p.11 (§5, p. 11).
  • 6 Auditor competence — competence requirements; starts p.13 (§6, p. 13).
  • Annex A: Audit checklist — one row per criterion with what to look for in the initial and surveillance audit; starts p.14 (Annex A, p. 14). Read
  • Annex B: Audit report outline [proposed] — six-section report outline; starts p.16 (Annex B, p. 16). Read
  • Annex C: References — reference tags with versions or dates; starts p.17 (Annex C, p. 17). Read
  • Annex D: FOR REVIEW and placeholder register — open points with origin; starts p.19 (Annex D, p. 19). Read

Key points​

  • The audit is evidence based; a process description alone does not demonstrate operating effectiveness (§2, p. 6).
  • The audit is performed by persons independent of the process audited and of the evaluation, in line with the impartiality required of the CB by [ISO/IEC 17065] (§2, p. 6).
  • [ISO 19011] is a useful informative reference; this instruction does not make it normative (§2, p. 6).
  • Confidential information is protected under the CB's accreditation obligations; source code and vulnerability details are shown to the auditor only as far as needed to verify the process (§2, p. 6).
  • The schedule follows the reference schedule of Annex IX of [IR 2981] and [NP002] section 7.1; the Regulation makes the schedule a recommendation; any other schedule must keep the certificate validity within five years and each evaluation within 12 months of the previous year's (§3, p. 7).
  • Year 0 initial audit ([NP001] section 6.1, phase 4): verifies that the four processes exist and are designed to meet the criteria; operating effectiveness is not assessed; stages: document review and walk-through with process owners (§3, p. 7).
  • Years 1, 2, 3 surveillance audit: operating effectiveness of at least version control, update and vulnerability management, and evaluation of changes impacting security using the delta assessment of [NP001] section 6.6; stages: document review, record sampling, interviews (§3, p. 7).
  • Year 4 audit within recertification: operating effectiveness of the maintenance processes with the criteria applied to the whole period since the last full evaluation; stages as surveillance plus reconsideration of the design of the processes (§3, p. 7).
  • Special audit (any time): triggered under [NP002] section 7.3, for instance after a vulnerability, a suspension or a change concluded as not covered; scope and stages set by the CB (§3, p. 7).
  • VC1: every release is uniquely identified (application identifier, version name, version code, build or release identifier) matching the functional certificate and the FIT ST (§4.1, p. 8).
  • VC3: a change of the signing key is notified to the CB before it is used (§4.1, p. 8).
  • CM1: planned changes are notified to the CB before implementation (§4.2, p. 8).
  • CM3: each change is assessed for security impact, including against the [NP001] section 6.6 list that shall not be concluded as covered without new analysis: user authentication protocol or factors, the interface with the WSCA-BE or WSCD, key handling, attestation handling, resilience mechanisms, trusted list and revocation handling, target platform API level, signing key, distribution channel (§4.2, p. 8).
  • CM4: changes to the TOE boundary, the assumptions on the operational environment, the environmental requirements, or the identity or version of a certified component are not treated as covered by delta assessment (§4.2, p. 8).
  • UD5: the Wallet Instance's mechanism for verifying, per wallet unit, that the platform satisfies the assumptions on the end user device remains effective after updates, including the minimum platform version (§4.3, p. 9).
  • VM1: vulnerability management policy and procedures take into account [ISO/IEC 30111] and meet Annex I to the Cyber Resilience Act as required by Article 5(7) of [IR 2981] (§4.4, p. 9).
  • VM4: critical vulnerabilities and active exploits are notified to the CB within 24 hours of discovery, high-severity vulnerabilities within 72 hours; other vulnerabilities and changes within the timeline of the scheme (§4.4, p. 9).
  • VM5: a vulnerability impact analysis report (VIAR) with the content of Article 5(5) of [IR 2981] is transmitted to the CB without undue delay (§4.4, p. 9; Annex A, p. 15).
  • VM7: publicly known and remediated vulnerabilities are disclosed and registered in the repositories of Annex V (§4.4, p. 9).
  • Evidence expectations from [EN 17640] 6.9.4.5: vulnerability scan reports no older than three months; a sample of remediation actions with remediation delays; a risk management analysis covering at least the 12 months before the evaluation with unambiguous version tracking; for the audit they are a reference for what a mature process leaves behind "[inferred use]" (§4.4, p. 9).
  • CV1–CV3: the functional certificate remains valid for the certified version and its suspension, withdrawal or expiry is notified to the CB without undue delay; the product developer monitors the validity, version and certification status of the WSCD certificate and of other certificates recorded as environmental requirements and notifies the CB of any change; the assumptions on the operational environment and environmental requirements of the Protection Profile remain valid for the lifetime of the certificate (§4.5, p. 10).
  • Findings: each criterion is recorded as met, not met, or not applicable with the reason (§5.5, p. 11). [Proposed] classes: Major (puts continued conformity in doubt, e.g. a missed 24 or 72 hour notification; reported to the certifying function; may lead to suspension under [NP002] section 9.2; remediation timeframe set by the CB), Minor (partly met or record missing; corrective action by a date set by the CB, verified at the next audit), Observation (an improvement that does not concern a criterion; recorded, no action required) (§5.5, p. 11).
  • The audit report is an input to the certification decision ([NP002] section 6.1) in the initial audit and to the surveillance report ([NP002] section 7.2) later (§5.6, p. 12).

Process​

  1. Planning (Lead auditor): sends the product developer the audit plan with scope, criteria, period, requested documents and records, and dates; for surveillance audits the period is the time since the last audit and the request includes the change log, vulnerability log, notifications sent to the CB and update release log (§5.1, p. 11).
  2. Document review (Auditor): reviews process documentation against the criteria and records per criterion whether the design meets it; principal activity in the initial audit (§5.2, p. 11).
  3. Sampling of records (Auditor), for operating effectiveness. [Proposed] sampling rule: all changes that the product developer or the CB classified as touching the [NP001] section 6.6 list; all vulnerabilities rated critical or high; all notifications to the CB; and an auditor-selected sample of others, with the sampling basis stated. Each sampled change is traced from request to release to the next delta assessment, each sampled vulnerability from discovery to notification, remediation and disclosure, checking the 24 and 72 hour limits against timestamps (§5.3, p. 11).
  4. Interviews and observation (Auditor; Auditee makes process owners available): interview the owners of the four processes and, where useful, observe a build or update release (§5.4, p. 11; §1.3, p. 5).
  5. Findings (Auditor records; Lead auditor decides): met / not met / not applicable per criterion, with the [proposed] Major/Minor/Observation classification (§5.5, p. 11; §1.3, p. 5).
  6. Audit report (CB): issued to the product developer with scope, period, criteria, evidence examined, sampling basis, findings with class, and conclusion; records kept for the period set by the Scheme Owner (§5.6, p. 12).

Requirements in this document​

All 24 entries are listed one by one, with their text and PDF page, on the NL-CS Part 4 requirements page. You can also search them together with all other requirements.

Notes on this draft​

  • The document uses two identifiers: "NL-CS (part4)" as Document reference and "NI003" on the cover and in every footer (cover, p. 1; Document control, p. 2; footer, p. 2–19). Its own reference table lists [NI003] as "0.9.4 for review, 24 October 2026" while the document is RC1.0 (Annex C, p. 17).
  • The cover page (p.1) shows no version or date; Document control gives Date "25/10/2026" while the history of changes gives "24 October 2026" (cover, p. 1; Document control, p. 2; Document control, p. 3).
  • Related documents in the Document control table are named "NL-WSCA & NL-WSCA-conditions" (not "NL-CS-WSCA") (Document control, p. 2).
  • Section 1.2 speaks of "The four processes of section 4"; section 4 has five subsections, the fifth being "Continued validity of the certification basis (CV)", which section 1.2 lists as a separate scope item (§1.2, p. 5; §4.5, p. 10).
  • Section 1.2 states: "Annex IX of [IR 2981] names version control, update and vulnerability management; [NP001] section 2.2 names change management, vulnerability management and update delivery. This instruction covers all of them [see the review point below]." (§1.2, p. 5); Annex D lists "Names of the processes; licensing evidence has no home in [NP001]" (Annex D, p. 19).
  • Annex D also lists: "VM1: CRA Annex I against the scope exclusion of [NP001] section 2.2"; "CV3: what must be monitored"; "Finding classes and remediation timeframes" (origin "[NP001] section 6.5; EZU review" — "EZU" is not expanded in the document); "Auditor competence criteria" (Annex D, p. 19).
  • Annex A row CV3 states "Monitoring approach [placeholder]" (Annex A, p. 15).
  • The role "Technical support" (Evaluation Laboratory), the sampling rule (5.3), the finding classes (5.5) and the Annex B report outline are marked [proposed] (§1.3, p. 5; §5.3, p. 11; §5.5, p. 11; Annex B, p. 16).
  • Section 2 qualifies the use of [ISO 19011] as "[inferred suitability, not checked against the standard text]"; section 4.4 qualifies the [EN 17640] evidence expectations as "[inferred use]" (§2, p. 6; §4.4, p. 9).
  • The surveillance audit row lists "at least version control, update and vulnerability management" and the "evaluation of changes impacting the security of the product, using the delta assessment of [NP001] section 6.6"; it does not use the term "change management" (§3, p. 7).
  • [ARF] "Version to be pinned"; [OWASP MAS] EUDI Wallet profile "draft, not released"; [ISO 19011] "Edition not pinned" (Annex C, p. 17–18).

Sources​