cyber-and-data

---
name: cyber-and-data
description: Turns the personal data your venue already holds, booking system, card terminal, CCTV, staff records, marketing list, Wi-Fi guest log, into a plain inventory, sets out your statutory 72 hour breach notification duty under UK GDPR Article 33 that applies whether or not you buy insurance, separates card payment data from ordinary personal data, maps what a standalone cyber and data insurance section is typically structured to cover, and checks that structure against what you actually hold so any gap is written down before it is a live incident. Use when you are buying, renewing or reviewing business insurance, when you are asked whether you hold cyber cover, or when you want to know what happens the day a laptop goes missing or a booking system gets emailed to the wrong person.
---

# A data inventory the insurer will ask for, the 72 hour duty in writing, and a cyber cover map checked against what you actually hold

You give this a plain list of where personal data sits in the business, your card payment set up, and your policy wording if a cyber or data section exists. You get back a data inventory an insurer or the ICO would recognise, the two statutory thresholds written out in the regulator's own words, a card payment data note that keeps PCI-DSS separate from UK GDPR, a cyber cover map that checks the policy's categories against what you hold, and a one page broker brief with every "not stated" listed as a finding. It will not decide whether a suspected incident meets the reporting threshold to the ICO, or the higher threshold for telling the individuals affected. Both of those are judgement calls about a specific set of facts, and the wrong call has consequences for people whose data it is, so the skill records the facts and leaves the call to the owner and, on the legal question, a data protection adviser.

## What it does

1. **Build the plain data inventory before anything else, because it is the first thing everyone downstream will ask for.** One row per system: the booking system, the card payment terminal and its provider, CCTV and how long footage is kept, staff HR records, the email or SMS marketing list, and the Wi-Fi guest log if the venue offers one. For each, write what is actually held, whose data it is, where it is stored, who else can access it, and whether it sits with a third party processor. This is not a technical audit. It is the list a cyber insurer's proposal form asks for on page one, and it is the list the ICO's own breach process needs on day one of a real incident, when nobody has time to work it out from memory.

2. **Fix the point the statutory duty starts, and note that it starts whether or not the business holds any insurance at all.** UK GDPR Article 33(1) states plainly: "In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the Commissioner, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons." The ICO's own guidance for small organisations is explicit about the starting point: "The clock starts from when you discovered the breach, not when it actually happened." A business with no cyber policy still has this duty. A business with a cyber policy still has this duty, and the policy pays for some of the response, it does not replace the legal obligation to respond within the deadline.

3. **Learn the two threshold tests, because mixing them up is the commonest small business mistake.** The lower threshold decides whether the ICO must be told at all: "If a risk is likely, you must notify us, as soon as possible, and where feasible within 72 hours." The higher threshold decides whether the individuals themselves must be told, and Article 34(1) sets it out: "When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay." A breach can clear the first threshold and not the second. It never clears the second without also clearing the first. Record both tests as questions to be answered on the day, not as a conclusion reached in advance.

4. **Separate card payment data from ordinary customer and staff personal data, because two different obligations run on two different tracks.** Card data is not governed by UK GDPR alone. The Payment Card Industry Data Security Standard sits outside UK statute, and the PCI Security Standards Council states its own limits plainly: "The Council's role is to develop and maintain standards. We do not monitor the implementation of standards. Whether an entity is required to comply with or validate compliance to a PCI SSC standard is at the discretion of organizations that manage compliance programs, such as a payment brand, acquirer, or other entity." In practice the obligation to complete an annual self-assessment questionnaire and keep card data secure sits in the merchant agreement with the acquirer or payment provider, not in a data protection statute. A venue storing card numbers in a spreadsheet or on a terminal receipt has both a UK GDPR problem and a PCI-DSS contract problem, checked in different places by different people.

5. **Treat the first hours of a suspected breach as a fixed sequence, not an argument about seriousness.** The ICO's small organisation guidance sets out what to do before any threshold decision is reached: log what happened, gather the facts, contain what can be contained, then assess the risk. A business does not get to decide a breach is minor and skip the log; the log is what a later reporting decision, by the owner or a data protection adviser, is actually based on. The guidance's own case study shows an initial no reversed once more facts emerged, an unencrypted laptop and unredacted case papers lost in a briefcase, where "on discovering the possibility of a risk to data subjects, the controller correctly reported the breach." Ransomware is treated the same way regardless of whether any data actually left the building: "where personal data is encrypted as the result of a ransomware attack, that constitutes a personal data breach because you have lost timely access to the data."

6. **Record the breach whether or not it is ever reported to the ICO.** Article 33(5) imposes a documentation duty that exists independently of the notification duty, requiring the controller to document every breach, its facts, effects and the remedial action taken. The ICO restates this directly: "You should ensure that you record all breaches, regardless of whether or not they need to be reported to the ICO." A venue that correctly decides a breach does not meet the reporting threshold still needs a dated record of that decision, because "we didn't think it was serious" with nothing written down is not the same thing as an assessed and documented decision.

7. **Map what a standalone cyber and data insurance section is typically structured to answer, as a set of categories, never as a promise of what will be paid.** Insurance market guidance on the shape of cyber cover, rather than any individual insurer's wording, groups the response into first party costs, the business's own losses, and third party costs, claims made against the business by someone else. First party categories typically include loss of or damage to digital assets, business interruption from network downtime, cyber extortion where a third party threatens to damage or release data unless paid, and customer notification expenses where there is a legal or regulatory requirement to notify. Third party categories typically include the investigation, defence costs and civil damages arising from a security or privacy breach, and compensation to third parties for loss of their data. PCI-DSS fines and card scheme costs, where insurable at all, sit as a further named category some policies address and others do not.

8. **Compare the policy wording against the data inventory, category by category, and write down every "not stated" as a finding rather than an assumption of cover.** If the venue holds a marketing list of several thousand emails but the notification cost category has no stated limit, that is a finding. If the venue takes card payments through its own terminal but the policy is silent on PCI-DSS fines, that is a finding. If there is no cyber or data section on the policy at all, record that plainly for the broker conversation rather than leaving it unmentioned because the venue is small. A pub, cafe or restaurant holding a booking system, a card terminal, CCTV and a staff list is holding exactly the categories of data a cyber section is written to respond to, and the absence of that section is a decision, even when nobody at the venue remembers making it.

9. **Hand the mechanical extraction and comparison to Codex, then build the one page broker brief from what comes back.** Run, from the folder holding the policy wording and the supplied facts:

   ```
   codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
   ```

   Claude hands over the data inventory facts, the card payment set up, the breach facts if a real incident is being logged, and the policy wording as supplied by the owner. Codex returns the data inventory register, the card data segregation note, the breach facts record, the cyber cover map, and a gaps file. Codex decides nothing about whether a breach meets either threshold and estimates no limit, excess or figure that was not supplied. Claude then writes the one page brief: the data inventory summary, the two thresholds in the regulator's own words, the card data note, the cover gaps, and the questions for the broker and, where the question is legal, for a data protection adviser or solicitor.

## Then it checks

1. Every system in the data inventory names what is held, where it sits and who else can access it, and no row reads only a system name with nothing else recorded.
2. The file states the Article 33 threshold and the Article 34 threshold separately, in the regulator's own quoted words, and does not collapse them into one test.
3. Every system that touches card payment data is marked separately from the ordinary personal data systems, and the PCI-DSS route is described as running through the acquirer or processor contract, not through UK GDPR.
4. Where a real suspected breach is being logged, the file records when the business became aware and what was done in response, and states plainly that the reporting decision itself has not been made by this file.
5. Every cover category named in step 7 is checked against the policy wording and marked present, absent or not stated, and every absent or not stated category appears in the gaps file.
6. If the policy has no cyber or data section at all, the brief says so as its own line, not folded silently into the general gaps count.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never state a typical cyber insurance premium, a typical claim value or a typical breach cost for a single independent UK hospitality business. No published figure exists for one venue, the figures that circulate come from insurers and vendors selling cyber products, and an owner who prices risk against a borrowed figure has no way to tell whether their own exposure is higher or lower.
- Never decide whether a suspected incident meets the Article 33 threshold for the ICO or the Article 34 threshold for the individuals affected. Both are judgement calls about a specific set of facts, and the file records the facts and the two tests in the regulator's own words, and leaves the call to the owner with, on the legal question, a data protection adviser or solicitor.
- Never treat the 72 hour duty as optional, negotiable, or contingent on holding a cyber insurance policy. The duty is Article 33 of UK GDPR, it runs from the moment the business becomes aware of a breach, and it applies identically to a venue with no policy at all.
- Never recommend an insurer, a broker, a policy or a limit to buy, and never describe one policy's cover as better, cheaper or more suitable than another's.
- Never treat an absent cyber and data section on the policy as evidence that a small venue does not need one. Record it as a finding for the broker conversation, because a venue holding a booking system, a card terminal, CCTV and a staff list is holding exactly the data a cyber section responds to.
- This output is a working document prepared for the owner's own FCA authorised insurance broker to check, and for a data protection adviser or solicitor on any question of whether a breach meets a notification threshold or the business otherwise complies with UK GDPR. It applies published rules to facts the owner supplied. It is not advice on which policy to buy, it is not a legal determination that a breach is or is not reportable, and it is not a ruling that the business complies with UK GDPR or the Data Protection Act 2018.

## Built from
- Information Commissioner's Office, "Personal data breaches: a guide", https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/, updated wording on PECR timescales dated 20 August 2025 as shown on the page, read 23 September 2026: the 72 hour reporting duty and the record-all-breaches instruction, in steps 2 and 6.
- Information Commissioner's Office, "UK GDPR data breach reporting (DPA 2018)", https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/, last updated 28 May 2025, read 23 September 2026: the likely risk test for ICO notification and the high risk test for individual notification, in step 3.
- Information Commissioner's Office, "72 hours: how to respond to a personal data breach", https://ico.org.uk/for-organisations/advice-for-small-organisations/personal-data-breaches/72-hours-how-to-respond-to-a-personal-data-breach/, read 23 September 2026: the clock starting from discovery rather than occurrence, the first hour sequence, and the low risk worked example, in steps 2 and 5.
- Information Commissioner's Office, "Personal data breach examples", https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breach-examples/, read 23 September 2026: the lost unencrypted laptop case study and its reporting outcome, in step 5.
- Information Commissioner's Office, "Ransomware and data protection compliance", https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/ransomware-and-data-protection-compliance/, read 23 September 2026: ransomware as a personal data breach through loss of access alone, and the low barrier to entry for small business attacks, in step 5.
- Information Commissioner's Office, "Self-assessment for data breaches", https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach-assessment/, read 23 September 2026: the instruction that the risk assessment and reporting decision is the controller's own, in step 3.
- Regulation (EU) 2016/679 as it forms part of UK law (UK GDPR), Article 33, https://www.legislation.gov.uk/eur/2016/679/article/33, read 23 September 2026: the 72 hour notification duty to the Commissioner and the documentation duty, in steps 2, 3 and 6.
- Regulation (EU) 2016/679 as it forms part of UK law (UK GDPR), Article 34, https://www.legislation.gov.uk/eur/2016/679/article/34, read 23 September 2026: the higher threshold for communicating a breach to the data subject, in step 3.
- PCI Security Standards Council, "About Us", https://www.pcisecuritystandards.org/about_us/, copyright range 2006 to 2026 as shown in the page footer, read 23 September 2026: who the standard applies to and that compliance is managed by payment brands and acquirers rather than by UK statute, in step 4.
- Lloyd's, "A Quick Guide to Cyber Risk", https://www.lloyds.com/insights/news/a-quick-guide-to-cyber-risk, dated 9 April 2015 as shown on the page, read 23 September 2026: the first party and third party category structure of a cyber policy, in step 7.

# cyber-and-data

## You are given
A plain description of every system holding personal data in one UK hospitality business: the booking system, the card payment terminal and its provider, CCTV and its retention period, staff HR records, the email or SMS marketing list, and the Wi-Fi guest log if one exists, each with what is held, where it sits, who can access it and whether a third party processor is involved. The venue's card payment set up, including the acquirer or payment provider name and any self-assessment questionnaire type and date the owner has supplied. If a real suspected breach is being logged, the date the business became aware of it, a plain description of what happened, which systems were affected, and what containment steps were already taken, all exactly as the owner describes them. The policy wording for any cyber or data section the business holds, or a plain statement that no such section exists. All judgement calls, including whether any incident meets a reporting threshold, whether a data item is special category data, and which insurance categories the business needs, have already been made, or explicitly left open, by the owner and are supplied to you as facts or as stated gaps, never as something for you to infer.

## Produce
Write into a `./cyber-and-data-output/` folder:

1. `data-inventory.csv` with these columns in this order: `system_ref`, `system_type`, `system_name_verbatim`, `data_held_description`, `categories_of_individuals`, `special_category_data_present`, `storage_location`, `processor_or_supplier_name`, `contract_or_dpa_in_place`, `retention_period_supplied`, `encrypted_at_rest`, `encrypted_in_transit`, `source_document`. `system_ref` is S001 upward. `system_type` is exactly one of `booking system`, `POS or card terminal`, `CCTV`, `staff HR records`, `marketing list`, `Wi-Fi guest log`, `other`. `special_category_data_present`, `encrypted_at_rest` and `encrypted_in_transit` are each exactly `yes`, `no` or `not stated`. `source_document` is the name of the document the owner supplied, or `not supplied`.
2. `card-data-segregation.csv` with columns: `system_ref`, `handles_card_payment_data`, `acquirer_or_processor_name`, `pci_dss_saq_type_supplied`, `last_saq_completed_date_supplied`, `pci_obligation_route`. `handles_card_payment_data` is `yes` or `no`. `pci_obligation_route` is always written exactly as `runs through the acquirer or processor merchant agreement, not through UK GDPR`. Rows where `handles_card_payment_data` is `yes` and `pci_dss_saq_type_supplied` is empty are listed in `gaps.md`.
3. `breach-facts.md`, produced only if the owner has supplied facts about a real suspected incident, otherwise write the single line `no suspected incident was supplied for this run`. Where facts are supplied, record on separate lines and nothing else: the date and time the business became aware, exactly as supplied; a verbatim description of what happened; the systems affected, referencing `system_ref` from `data-inventory.csv`; the categories of data involved; the containment actions already taken, verbatim; the calculated 72 hour notification deadline from the date and time of awareness, shown as a date and time and labelled `72 hour deadline if the ICO threshold is met, calculated from the supplied awareness time`; and the line `whether this breach meets the Article 33 or Article 34 threshold has not been assessed here and is a decision for the owner with their data protection adviser`.
4. `cyber-cover-map.csv` with columns: `policy_ref`, `insurer_name_verbatim`, `policy_document_name`, `cover_category`, `cover_type`, `stated_in_policy`, `limit_or_sublimit_gbp_verbatim`, `excess_verbatim`, `source_page_reference`. `cover_category` is exactly one of `forensic investigation costs`, `customer or individual notification costs`, `business interruption from a cyber event`, `cyber extortion or ransom`, `liability to affected individuals`, `regulatory investigation and defence costs`, `PCI-DSS fines and card scheme costs`. One row per category per policy, produced even where the category is entirely absent from the wording. `cover_type` is exactly one of `first party` or `third party`. `stated_in_policy` is exactly one of `yes`, `no` or `not stated`. Where no cyber or data section exists at all, write one row per category with `policy_ref` set to `NONE`, `stated_in_policy` set to `no`, and every other field left empty.
5. `data-to-cover-gaps.csv` with columns: `system_ref`, `system_type`, `relevant_cover_category`, `cover_status`, `finding`. For every row in `data-inventory.csv`, match it against the relevant category or categories in `cyber-cover-map.csv` and record whether that category is stated, absent or not stated. `finding` is a short verbatim restatement of the gap, for example `marketing list held, customer notification cost category not stated in policy`.
6. `gaps.md`, a numbered list of: every data inventory row with no processor or supplier name; every system marked `handles_card_payment_data` yes with no SAQ type supplied; every cover category marked `no` or `not stated` against a system that holds the relevant data; the fact, on its own numbered line, if no cyber or data section exists on the policy at all; any supplied fact with no date attached; and any supplied text containing an em dash character, quoted verbatim and flagged.

## Rules
- Codex records, counts, matches and calculates a notification deadline from a supplied awareness time. It never decides whether an incident meets the Article 33 or Article 34 threshold, never marks a data item as special category data unless the owner supplied that fact, and never estimates a limit, an excess or a cover category as present when the wording does not say so.
- Never mark a cover category `yes` from the absence of an exclusion. Only a category the policy wording positively states is marked `yes`. Silence is `not stated`, an express exclusion is `no`.
- Never write a typical premium, a typical claim value, a typical breach cost or any industry benchmark figure into any file. No such figure exists for a single independent UK venue and none is to be recorded.
- Never carry a system, a policy limit or a categorisation forward from a previous run's file. Each run works from what is supplied this time.
- Never publish a conclusion on whether a suspected breach is reportable. `breach-facts.md` records facts and the calculated deadline only, and states plainly that the threshold decision has not been made.
- Use British English, GBP written as `GBP` or the pound sign, and DD Month YYYY dates. No em dashes in any file you write, and any supplied text containing one is recorded verbatim in the relevant file and flagged in `gaps.md`.
- Every quoted system name, policy wording extract and supplied description is copied exactly, including its punctuation and capitalisation.
- Every file ends with this line: this is a working document prepared for the owner to check against their own policy wording and supplier contracts, and for their FCA authorised insurance broker and, on any question of whether a breach must be reported, a data protection adviser or solicitor, to check before any decision is acted on. It applies supplied facts to a set of named categories and is not a ruling that a breach is reportable or that the business complies with UK GDPR.

## Return
The absolute path of every file written, the row count of each CSV, the count of systems in `data-inventory.csv` by `system_type`, the count of systems marked `handles_card_payment_data` yes and how many of those have no SAQ type supplied, whether `breach-facts.md` recorded a real incident or the no-incident line, and if it recorded one, the calculated 72 hour deadline stated in full, the count of cover categories marked `yes`, `no` and `not stated` in `cyber-cover-map.csv`, whether any policy row used `policy_ref` `NONE` meaning no cyber section exists at all, and the `gaps.md` item count.