Register operational · Records verified against workshop evidence
Login
Governance framework · Instrument

Information Security Policy

The controls applied to protect the confidentiality, integrity and availability of register data, evidence files and account credentials.

Document reference
NVSR-SEC-001
Version
1.0
Status
In force
Effective date
1 August 2026

1.Scope and objectives

1.1

This Policy applies to all systems, data and personnel involved in operating the Register, including the public website, the workshop and administration areas, the database, the evidence and certificate stores, and any sub-processor engaged by the Register.

1.2

The Register's security objectives, in priority order, are: (a) the integrity of published records, (b) the confidentiality of personal data and evidence, and (c) the availability of the public register.

1.3

Integrity ranks first because a register whose entries can be altered without trace has no value. Controls are designed accordingly: destructive operations are constrained at database level rather than only in the interface.

2.Encryption

  • All traffic between users and the Register is carried over TLS. Plain HTTP is redirected and not served.
  • Data at rest, including the database, evidence files, workshop documents and issued certificates, is encrypted by the hosting platform using industry-standard block encryption.
  • Passwords are never stored in recoverable form; they are held only as salted one-way hashes by the authentication service.
  • Credentials for third-party services are stored as platform secrets, injected at runtime, and never committed to source or exposed to the browser.

3.Access control

3.1

Access is enforced at the data layer through row-level security policies, not merely by hiding controls in the interface. A request that is not entitled to a row does not receive that row, whatever route it arrives by.

3.2

Roles are held in a dedicated role table and evaluated server-side. A user cannot elevate their own privileges, and role state held in the browser has no effect on what the database will return.

3.3

Access follows the least-privilege principle:

  • A workshop may read and write only its own records, members, insurance and qualification entries.
  • A vehicle owner may read entries for a vehicle they have claimed, and control the visibility permitted to them under the Public Register Data Policy (NVSR-PRD-001).
  • Administration and compliance roles may read what is necessary to review, and every such action is written to the audit trail.
  • Privileged service credentials are used only for defined server-side operations, never for ordinary reads, and never to decide whether a caller is an administrator.
3.4

All private files — evidence, workshop documents, case attachments and certificates — are held in non-public storage and released only through short-lived signed links issued to an entitled party.

4.Record integrity controls

  • A published entry cannot be edited in place; database-level protection rejects modification of published, amended or withdrawn records.
  • Corrections proceed only by amendment, which increments a version number and writes an immutable snapshot of the superseded version.
  • Certificate identifiers are unique and permanent; a superseded certificate remains resolvable and is marked as superseded rather than deleted.
  • Audit events cannot be updated or deleted by any application role.

5.Logging and monitoring

5.1

The Register writes an audit event for every material action: publication, amendment, verification decision, enforcement action, restriction of a record, role change, and access to a private document.

5.2

Automated integrity monitoring runs on a scheduled basis and raises risk events for indicators such as implausible mileage progression, duplicated evidence, expiring or lapsed insurance, and expired technician qualifications.

5.3

Operational logs are retained under the Data Retention and Disposal Schedule (NVSR-DRP-001) and are accessible only to administration personnel.

6.Sub-processors and infrastructure

6.1

The Register operates on managed cloud infrastructure and engages a small number of sub-processors for hosting, database, authentication, file storage and content delivery. Sub-processors are engaged under written terms imposing confidentiality and security obligations equivalent to those in this Policy.

6.2

Register data is hosted within the United Kingdom or the European Economic Area. Any transfer outside that area is made only under an adequacy regulation or the International Data Transfer Agreement, as described in the Privacy and Data Protection Policy (NVSR-GDPR-001).

6.3

MOT data is retrieved from the Driver and Vehicle Standards Agency MOT History service. The Register transmits only the vehicle identifier necessary to perform the lookup.

7.Development and change control

  • All input is validated against a schema on the server, irrespective of any validation performed in the browser.
  • Database structure changes are applied as versioned migrations with an accompanying access-rule review.
  • Dependencies are monitored for published vulnerabilities and updated on a risk-assessed basis.
  • Security-relevant changes are recorded in the audit trail and, where they affect published behaviour, in the governance framework.

8.Incident response

8.1

A suspected incident is triaged immediately on detection. The response sequence is: contain, assess scope, preserve evidence, remediate, and record.

8.2

Where an incident constitutes a personal data breach likely to result in a risk to the rights and freedoms of individuals, the Register notifies the Information Commissioner's Office without undue delay and within 72 hours of becoming aware of it.

8.3

Where the breach is likely to result in a high risk to affected individuals, those individuals are informed directly and without undue delay, in plain language, with the steps they should take.

8.4

Every incident, including those not meeting the notification threshold, is recorded in an internal breach register with the facts, effects and remedial action taken.

9.Reporting a vulnerability

9.1

Security researchers are invited to report suspected vulnerabilities through the contact form under category C6, with sufficient detail to reproduce the issue.

9.2

The Register will acknowledge a report with a case reference immediately, provide an initial assessment within 5 working days, and will not pursue action against a researcher who acts in good faith, avoids privacy violations and service degradation, and does not exfiltrate, alter or publish register data.

9.3

Testing must not include denial-of-service, social engineering of personnel or workshops, physical attacks, or automated scanning that degrades availability.

10.Review

This Policy is reviewed at least annually and after any material incident or infrastructure change. Each review issues a new version under the same document reference.

Document control
Reference
NVSR-SEC-001
Version
1.0
Classification
Public
Review
Annually