From an empty workspace to a running practice.

Create your workspace

The first time you open the on-device portal it asks for a practice name and a passcode. That passcode is not a login — on this version there is no account and no server to log in to. It is the key that encrypts your workspace.

Want it on more than one machine? Create an account instead, or move this workspace onto one later. The encryption is identical either way; the difference is whether we hold a sealed copy we cannot open.

1. Open the portal and enter your practice name as you would like it to appear on generated documents.
2. Choose a passcode of at least eight characters. Veld runs it through PBKDF2 to derive an AES-256 key, then seals the workspace with it. The passcode itself is never stored anywhere.
3. Take the welcome tour — four steps, about a minute. You can replay it any time from Replay the tour at the bottom of the sidebar.

Unlocking with a passkey

Once the workspace exists you can add a passkey and open it with Face ID, Windows Hello, your phone or a security key instead of typing the passcode. Go to Settings → Passkeys → Add a passkey.

This is not a login. On the on-device portal there is still no account and no server — the passkey asks your device for a secret only it can produce, and that secret unlocks the workspace. Nothing is transmitted.

• You can add several — a laptop, a phone, a hardware key — and each works independently.
• The passcode stays and cannot be removed. It is the recovery route if a device is lost, which is also why adding a passkey does not let you forget the passcode.
• A passkey is tied to the domain it was created on, so one made on veldprivacy.co.uk will not open a copy of the portal running anywhere else.

Everything lives in this browser, on this machine. Clearing site data or losing the laptop loses the workspace, which is why the last walkthrough is not optional.

Add the organisations you advise

Every request, register entry and assessment hangs off a client, so this comes first. A client is any organisation you advise, whether you are their outsourced DPO, a retained consultant or covering a single project.

1. Go to Clients → Add client.
2. Record the data role. Controller, processor or joint controller changes what the organisation is actually responsible for — and therefore what you should be advising. Get it right at the start and the rest of the record stays coherent.
3. Add a key contact. Letters you generate later address themselves to this person.
4. Use notes for the things that are true of the relationship rather than any one matter: retainer scope, review dates, the quirk you will otherwise forget by March.

Deleting a client removes its requests, register entries and assessments too. Veld warns you first, because that is rarely what you meant.

Log a request and start the clock

This is the part that earns its keep. Log the request on the day it arrives and the deadline maintains itself.

1. Go to DSARs → Log a DSAR, or use the button on the dashboard.
2. Pick the client and describe the data subject in a way you will recognise in six weeks — "Tenant, flat 12B" beats "DSAR 4".
3. Choose the right being exercised. Access is the common one, but erasure, rectification, portability, restriction and objection all run on the same clock.
4. Set the date received. Veld immediately shows the statutory deadline underneath, so you can see it before you save.

How the calendar-month rule works

UK GDPR works in calendar months, not thirty-day blocks. The deadline is the corresponding date in the next month — a request received on 3 September is due on 3 October. Where that date does not exist in the target month, it clamps to the last day, which is why:

When to apply the extension

You may take two further months where a request is complex or where you have received a number of requests from the same person. Tick Apply the two-month extension and the clock recalculates to three months from receipt.

When the clock does not start

The period does not begin on the day the request lands if you reasonably need something before you can answer it. Two cases come up constantly:

• Identity verification. Where you cannot be confident who you are dealing with, the time limit runs from the date the identification arrives — not the date of the request.
• Clarification. Where you process a large quantity of information and the request is genuinely unclear, asking what they actually want also holds the clock.

Open a request and use Stopping the clock to record when each was requested and received. While something is outstanding the tracker shows Clock not started rather than a countdown, and the request is excluded from the calendar export — because there is no deadline yet to put in a diary. Enter the date it arrives and the deadline calculates from there, with the original date of receipt kept on the record.

Reading the dashboard

The statutory clock lists every open request, most urgent first, with a bar showing how much of the period has gone. Where the pressure is splits the same requests into overdue, due within seven days, and on track — each with an icon and a label, so the state is never carried by colour alone.

Record a breach and start the 72-hour clock

The breach register is the one part of the portal that works in hours rather than days. Article 33 gives you 72 hours from becoming aware to notify the ICO where a breach is likely to result in a risk to people's rights and freedoms — and Article 33(5) requires a record of every breach, including the ones you decide not to report.

1. Go to Breaches → Record a breach. It gets a reference automatically (BR-2026-001).
2. Set became aware carefully. This is the moment you knew, not the moment the incident happened — the clock runs from awareness, and the two are often days apart. Record the incident date separately if you know it.
3. Capture the categories and approximate numbers of data subjects and records. Approximate is fine and expected; the ICO would rather have a range early than an exact figure late.
4. Set the assessed risk — to the rights and freedoms of the individuals, not to the organisation. That distinction is what drives everything downstream.

Deciding whether to notify

Open the record and set the ICO notification decision, with your reasoning. The reasoning field is not optional housekeeping: where you decide a breach is not notifiable, the documented justification is your compliance with Article 33(5), and it is the first thing asked for if the decision is later questioned.

Where you mark the risk as high, the record flags Article 34 — the affected individuals must be told without undue delay, unless the data was unintelligible to whoever received it, you have since neutralised the risk, or telling them individually would take disproportionate effort.

What comes out of it

• An ICO notification draft as a Word file, structured to Article 33(3) — nature, numbers, DPO contact, likely consequences and measures. If you are past 72 hours it adds a section for the reasons for the delay, which must accompany a late notification.
• The breach register as a spreadsheet: the full Article 33(5) record, notified and not-notified alike.
• Calendar events with alerts at 24, 6 and 1 hours before the deadline, rather than the day-based reminders used for subject access requests.

Build the Article 30 register

Article 30 asks for a record of processing activities. The reason most registers are painful is that they get reconstructed months later, from memory, the week somebody asks. Build it a row at a time instead.

1. Go to ROPA → Add activity and pick the client.
2. Name the activity the way the organisation would — "Tenancy management", not "Processing operation 1".
3. Record the purpose and the lawful basis separately. They are different questions and conflating them is the most common weakness in a register.
4. Add categories, recipients and retention. Retention is the field auditors probe hardest, so write the actual rule — "6 years after tenancy ends" — rather than "as required".

When somebody asks to see the register, Export register produces an Excel workbook with one sheet per client, filters on, header row frozen.

Track an impact assessment

A DPIA is required where processing is likely to result in a high risk — new or novel technology, large-scale special category data, systematic monitoring of a public area, automated decisions with legal effects.

1. Go to DPIAs → New DPIA and name the project as the client refers to it.
2. Set an initial risk. It is a starting position, not a verdict — the point of the assessment is to move it.
3. Write the summary for a reader who was not in the room, and record mitigations as you agree them.
4. Move the status from Draft to In review to Signed off so the state of every assessment is visible from the list.

Where residual risk stays high after mitigation, you must consult the ICO before starting. Veld tracks the assessment; that judgement stays yours.

Generate documents and reports

The Documents page turns what you have recorded into things you can send. Every file is generated in your browser — no upload, no third-party service, nothing that would make Veld a processor of your clients' data.

Word and Excel files open natively and are yours to edit — Veld writes real .docx and .xlsx, not renamed CSVs. Letters fill in the dates, the client name and your practice details from the record.

Building the disclosure bundle

Assembling a response is the fiddly part of a subject access request: files arrive named whatever the person who saved them felt like, and the schedule gets written last, from memory. Veld does the renaming as the documents arrive.

1. Open the request and choose Disclosure bundle, or pick it from the Documents page.
2. Check the bundle reference. It defaults to the client's initials and the subject — HHA-TENANTFLAT12 — and prefixes every document. Edit it if the client uses their own convention.
3. Drag the response documents in, or click to browse. Each one is renamed immediately to REF-DOC001-original-name.pdf, numbered in order.
4. Set a treatment per document: disclose, redact then disclose, or withhold. The last two ask for a reason, which appears on the schedule.
5. Download the bundle. You get a zip containing the disclosable documents and the schedule as a spreadsheet. Anything marked withhold is left out of the zip but stays on the schedule with its exemption, which is what makes the schedule defensible.

Scanning for personal data

Once documents are in the bundle, Scan for personal data reads them and lists what it finds — so you review decisions instead of hunting for them. The scan runs entirely in your browser. Nothing is uploaded, no AI service sees the documents, and Veld holds nothing as a result of it.

It looks for three things, in descending order of reliability:

1. Names already on the request. If the subject is logged as “Patient — A. Okafor”, every mention of Okafor is found with certainty rather than guesswork. This is why logging the subject properly pays off.
2. Validated identifiers. NHS numbers are checked against their modulus-11 check digit, National Insurance numbers against the allocation rules, and card numbers by Luhn — so a ten-digit invoice number is not reported as a patient record.
3. Patterns and name heuristics. Postcodes, phone numbers, dates of birth, salutations, sign-offs and common forenames. Useful, and the weakest of the three, so it is marked as lower confidence.

Export findings produces a spreadsheet of everything found, with the reason each item was flagged and its surrounding context — a working list to redact against, and a record of what was checked.

PDFs cannot be scanned yet. Reading text out of a PDF correctly needs a full PDF engine, and a partial one would quietly miss content and report a clean result — which is worse than declining. Word, Excel, PowerPoint, text and CSV files all scan.

Put deadlines in your calendar — and back up

Veld will not email you a reminder at seven in the morning, and on a synced account that is a consequence of the design rather than a missing feature: the server holds your workspace as ciphertext, so it cannot read a deadline in order to remind you of one. What it can do is put the deadlines into the calendar you already check.

1. From the dashboard or the DSAR tracker, choose Add to calendar.
2. Open the downloaded .ics file. Outlook, Google Calendar and Apple Calendar all accept it.
3. Each deadline arrives as an all-day event carrying alerts at 14 days, 7 days and 1 day before. Those alerts fire from your calendar — on your phone, offline, whether or not Veld is open.

Re-export whenever you log new requests; existing events update rather than duplicate, because each one keeps a stable identifier.

Backing up

1. Go to Settings → Export workspace.
2. Store the JSON file somewhere you would be content to store client data.
3. To move to another machine, open the portal there and use Import workspace.

The calendar, the health score and the evidence log

Three things computed entirely in your browser — no AI, and nothing a server could work out on your behalf even if you sync, because it only ever holds ciphertext. Between them they turn the portal from a record of what happened into a picture of where a client stands.

The compliance calendar

Statutory clocks are handled elsewhere. This is for the cyclical work that otherwise lives in your head — register reviews, DPA renewals, retention disposal, training.

1. Open Calendar. If clients already have records, Suggestions proposes a schedule — each one saying why, such as “two activities record a retention period, but nothing schedules the disposal”. These are rules reading your records, not guesses.
2. Accept the ones you want. Nothing is scheduled until you do.
3. When an obligation falls due, open it and mark it complete. You must record what was done — that note is the difference between a schedule and evidence.
4. Completion rolls the next date forward automatically. Skip moves one occurrence without claiming it was done, and the skip is recorded.

Obligations join the calendar export alongside statutory deadlines, with a month's notice rather than a day's.

The health score

A score per client on the Clients list and in the client record. It is arithmetic, not judgement: six weighted components computed from your own records, each shown with its weight, its value and the reason for it. You can disagree with it line by line, which is the point — a score you cannot interrogate is one you will eventually be asked to justify and cannot.

Two deliberate behaviours. A component with no data reads not assessed rather than scoring zero, so a client with no breaches is not penalised for having none. And a client with nothing recorded at all is not scored, because an empty record is not a weak one.

The evidence log

Every action is recorded with a SHA-256 hash committing to the entry before it. Altering or removing an entry breaks every hash after it. Settings → Verify the chain checks it and names the first entry that fails; Export evidence log produces a spreadsheet including the hashes.

The Radar and the registers

Two additions that change how the portal is used day to day: one place that tells you what to do next, and the registers that feed it.

Privacy Radar

The dashboard now opens with a single ranked list answering one question: what needs me today? It draws from everything — statutory clocks, the breach window, overdue reviews and actions, policies past their review date, suppliers without an agreement, gaps in the Article 30 register, assessments stuck in draft, and whether you have backed up recently.

1. Ranking is computed, not assigned. An overdue statutory deadline and a breach inside its 72-hour window sit at the top because of what they are, not because someone decided they should.
2. Each row opens the record it refers to, not the page it lives on. Click an overdue request and you are in that request.
3. Deal with something and it leaves the list. The Radar is a worklist, not a report.

The registers

A single page with four tabs, sitting alongside the Article 30 register you already have.

1. Vendors. Each processor with its Article 28 status, transfer position and sub-processors. Veld computes a risk score from those — a missing agreement and an unprotected international transfer will push a vendor to High — and shows the reasoning. It is a triage aid for what to look at first, not an assessment.
2. Policies. Notices, retention schedules and internal policies with their approval and review dates. Anything past review appears on the Radar.
3. Actions. The small things that fall out of a review. Closing one requires recording what was done, because an action closed without evidence is just a deleted reminder.
4. AI systems. What AI each client has adopted, linked to the vendor behind it, the processing activity it performs and the assessment covering it. A system with nothing linked is flagged — that gap is usually the finding.

What this does to the health score

The score now covers eight areas rather than six: DSAR management, ROPA completeness, impact assessments, breach handling, reviews, policies, evidence and outstanding actions.