Registers

Frameworks don’t only ask what technology you run. They ask whether you keep certain records, and keep them up to date: a risk register, a supplier list, an incident log, training records. Registers is where those records live in 786 Cyber.

Find it under Policy & Process → Registers in the side navigation (/registers). The risk register, supplier register, training register, incident register and the privacy records (processing, rights requests and DPIAs) are live now, and any active policy in the Policy Vault can be sent to people to acknowledge. They all work the same way.

The risk register

Open Registers → Risk register (/registers/risks). Each risk records:

• What could happen: a title, a description and a category.
• How serious it is: likelihood and impact on a 1–5 scale. Score = likelihood × impact, up to 25. A score of 12 or more is outside appetite, and is flagged in orange or red.
• What you’re doing about it: a treatment (reduce, avoid, transfer or accept) and a treatment plan. Optionally, a residual likelihood and impact: how serious the risk is once your treatment is in place.
• Who owns it, and who accepted it: an owner, a department and, for an accepted risk, the person who signed it off. You can add an acceptance expiry date for a time-limited exception.
• When it’s next reviewed. A new risk is due for review a year after you add it.

The page shows four counts at the top (open risks, outside appetite, reviews overdue, acceptances expiring in 30 days) and a 5×5 heat map. Select a cell on the heat map to filter the table to the risks in it. The heat map uses the residual score where one has been assessed.

Adding risks

There are three ways, as everywhere in 786 Cyber:

1. New risk: fill in the form.
2. Import CSV: bring in an existing spreadsheet through the Import Wizard. Map your columns, check the preview, then import. Title, likelihood and impact are required. Owners are matched by email address to your People directory. You can undo an import within 24 hours.
3. From findings: when you mark a scan finding as Accepted Risk, that’s a risk decision. The register offers to create entries from those findings, linked to the finding and its asset, with your acceptance note as the treatment plan. On any finding, Raise as risk in the risk register creates a draft risk for you to complete.

Reviewing risks

Open a risk and select Mark reviewed, optionally with a note on what changed. This records the review and sets the next review date a year ahead. Each risk’s Activity section keeps a dated record of reviews and changes, with who made them.

Every morning, owners and organisation admins get one email listing risks whose review is due within 14 days or overdue, and accepted risks whose acceptance is expiring or has expired. Each item is repeated at most once a week.

Linking and evidence

In a risk’s drawer you can:

• link the assets, findings and people it relates to;
• attach evidence from your Evidence Vault, such as board minutes, a risk assessment report or a sign-off email.

The supplier register

Open Registers → Supplier register (/registers/suppliers). Each supplier records:

• What they provide, a category, and how critical they are: from critical (the business stops without them) to low (easily replaced).
• Data and location: the most sensitive data they hold, whether they process personal or special-category data, and the countries where your data is hosted.
• Contract and exit: contract start and end dates, whether you have an exit plan, a contact, and any regulator approval reference (for example a SAMA or CBUAE non-objection for outsourcing).
• Owner and assessment: who owns the relationship, when it was last assessed, and when the next assessment is due (a year after the last).

Assurance documents are the evidence that a supplier is secure: a SOC 2 report, an ISO 27001 certificate, a PCI attestation and so on. Upload each one to the Evidence Vault with its expiry date, then attach it in the supplier’s drawer. The table shows each supplier’s assurance as current, expiring soon, expired or none attached. The page counts critical and high suppliers without current assurance, because that’s usually the first thing an auditor asks about.

Adding suppliers

1. New supplier: fill in the form.
2. Import CSV: only the supplier name is required. Personal data accepts yes or no, and hosting countries can be a list such as GB; IE. Suppliers already in the register are skipped. You can undo an import within 24 hours.
3. From your cloud services: the register offers to create a supplier for each vendor of the cloud services in your asset directory, linked to those assets. Suppliers created this way are marked not yet assessed: check the details, attach their assurance documents, then select Mark assessed. If your cloud-service assets have their Vendor field filled in, services from the same company are grouped under one supplier; otherwise each is named after the service.

Assessing suppliers

Open a supplier and select Mark assessed, optionally with a note on what you checked. The daily email also covers suppliers: assessments due or overdue, contracts ending within 30 days, and assurance documents expiring or expired.

The training register

Open Registers → Training register (/registers/training). It has two parts.

Courses are the training people must complete: security awareness for everyone, role-based training (for example developers or finance), director briefings and phishing simulations. Each course has a refresh cycle in months (leave it blank for once-only training), says whether it is mandatory, and applies to everyone in your People directory or to one department. Each course also has an owner and a yearly content review, so the material itself is kept current.

Completions record who completed a course and when. A completion expires when the refresh cycle runs out, and the register shows each one as current, expiring soon (within 30 days) or expired. The course table shows, for each course, how many people are current, and how many have expired or never completed it. People who have left (marked offboarded in the People directory) aren’t counted.

Recording training

1. Record completion: choose the course and the date, then tick everyone who attended. One session can be recorded for a whole team at once.
2. Import CSV: import the completion report from your training provider. Person email, course and completion date are required; score is optional. People must already be in your People directory. A course named in the file that isn’t in the register yet is added with a 12-month cycle. Completions already recorded for the same person, course and day are skipped, so importing the same report twice is safe. You can undo an import within 24 hours. Download CSV template in the Import Wizard gives you the columns.
3. Certificates: open a completion and attach the certificate or provider report from your Evidence Vault.

Each person’s page in the People directory shows the mandatory training that applies to them, and whether they’re current.

The daily register email lists, per course, how many people’s training has expired or expires within 14 days, and courses whose content review is due.

Policy acknowledgements

Frameworks expect people to have read and accepted your policies, not only for the policies to exist. Open any active policy in the Policy Vault. The panel under Metadata shows how many people have acknowledged the current version.

• Request acknowledgement emails everyone who hasn’t acknowledged the current version a personal link. They don’t need a 786 Cyber account. The link opens the policy, read-only, with an Acknowledge button. Each link works once and expires after 30 days. Sending a new request replaces any earlier link to that person.
• If you use 786 Cyber yourself, select I have read this policy to acknowledge it in the app.
• Show people lists everyone, with their status: acknowledged, requested, earlier version only or not requested. You can resend a link from there.

An acknowledgement counts only for the exact version and wording it was given for. If you change the policy’s text, earlier acknowledgements show as earlier version only, and you can ask people to acknowledge the new version. A policy must be finalised (active) before you can request acknowledgements; drafts can’t be sent.

Each person’s page shows which active policies they have acknowledged.

The incident register

Open Registers → Incident register (/registers/incidents). Record every security incident here, not only the serious ones, and every personal data breach, including those you decide not to report. Data protection laws expect that record.

Each incident records what happened, a category and severity, when you became aware (the notification clocks start here), whether it is a personal data breach and roughly how many people are affected, an owner, a timeline of events, and what you did: containment, root cause, and lessons learned and actions.

Notification clocks

Tick the notification rules that apply to the incident. 786 Cyber suggests the ones for the frameworks you assess; check with your adviser if unsure. Each rule adds its deadlines, worked out from the time you became aware:

Rule	Deadlines
EU GDPR, UK GDPR	Supervisory authority (the ICO in the UK): 72 hours
NIS2	Early warning: 24 hours. Incident notification: 72 hours. Final report: one month after the notification
DORA	Initial notification: 24 hours (and within 4 hours of classifying the incident as major). Intermediate report: 72 hours after the initial notification. Final report: one month after the intermediate report
Saudi PDPL	SDAIA: 72 hours
UAE PDPL	UAE Data Office: “immediately”; 786 Cyber uses 24 hours until the Executive Regulations set a clock
Qatar, Bahrain, Oman	Regulator: 72 hours
Kuwait (CITRA licensees)	CITRA: 24 hours
HIPAA	Affected individuals, and HHS for 500 or more people: 60 days

Each deadline shows as a countdown: amber while running, orange in the last 24 hours, red once passed. When you have notified, select Record notification with the time and the regulator’s reference. The clock stops, and any follow-up report’s clock starts from the time you actually notified. Duties without a fixed deadline, such as telling affected people “without undue delay”, aren’t given a clock; record them in the timeline.

When a deadline is 24 hours away, and again when it passes, organisation admins and the incident owner get an email straight away, not in the daily digest. Each alert is sent once.

The deadlines come from 786 Cyber’s framework guides. They’re a working aid, not legal advice: confirm the rules that apply to you.

Recording incidents

1. Record incident: fill in the form when something happens.
2. From Credential Breach Monitoring: on a person’s page, Raise as incident on a breach hit creates a draft incident linked to that person. A staff credential in someone else’s breach isn’t automatically a personal data breach of yours, so no clock starts until you decide.
3. Import CSV: bring in your existing incident log (title and detected date are required). Imported incidents are history, so no clocks start. You can undo an import within 24 hours.

When you close an incident, a post-incident review falls due 30 days later. Open the incident and select Mark reviewed once it’s done; the daily register email reminds owners and admins until then. Link the affected assets, people and suppliers, and attach evidence such as the regulator’s acknowledgement.

Privacy records

Three registers cover what data protection laws (GDPR, UK GDPR and the GCC laws) ask you to keep.

Record of processing

Open Registers → Record of processing (/registers/processing). Each processing activity (payroll, recruitment, customer accounts, marketing and so on) records its purpose, whether you are controller or processor, the lawful basis, the people whose data it is and the categories of data, any special-category data and the condition you rely on, its classification from your scheme in Settings, recipients, international transfers with the safeguard used (adequacy, standard contractual clauses, the UK IDTA, a regulator permit and so on), retention, and a description of the security measures.

• Link the systems (assets) the data lives in and the suppliers who process it. Linked suppliers are listed as recipients in the export.
• Assets marked as holding personal data that aren’t in any activity are listed at the top; select one to start an activity linked to it.
• Export Article 30 PDF produces the record of processing activities. Any field the record should contain but you haven’t filled in shows as Not recorded.
• Import CSV brings in an existing spreadsheet; transfers can be written like US:scc; IN:adequacy. You can undo an import within 24 hours.
• Each activity is due for review a year after it was added or last reviewed.

Rights requests

Open Registers → Rights requests (/registers/rights-requests). Log each request (access, rectification, erasure, restriction, portability, objection, automated decisions, withdrawing consent) with who made it, when it arrived and which law it falls under. The due date is worked out for you:

Law	Deadline
EU GDPR, UK GDPR	One month; can be extended by two months for complex requests
Saudi PDPL	30 days; one 30-day extension
Qatar	30 days
Bahrain	15 working days (Friday and Saturday aren’t working days)
Oman	45 days
UAE, Kuwait	No deadline in the law yet; 30 days is suggested as an internal target

An extension needs a reason and can’t go past the law’s limit. Admins and the request owner get an email straight away 24 hours before the deadline and if it passes. The page shows the share of requests answered on time over the last 12 months. The PDF export leaves out requesters’ names and contact details.

DPIAs

Open Registers → DPIAs (/registers/dpias). A data protection impact assessment records the processing, why it is necessary and proportionate, the risks to people, the measures that reduce them, the residual risk and the outcome. Link it to the processing activity it covers. Sign off records who approved it and sets a yearly review. If the residual risk stays high, the form reminds you that the regulator usually has to be consulted first.

How registers count towards your frameworks

A register counts as evidence only when it’s in use: at least one risk assessed or reviewed in the last 12 months, at least one supplier assessed by a person in the last 12 months, at least one person with a current (not expired) training completion, at least one person who has acknowledged the current version of an active policy, at least one incident recorded or reviewed in the last 12 months, at least one processing activity reviewed in the last 12 months, at least one rights request logged in the last 12 months, or at least one DPIA signed off or reviewed in the last 12 months. Having no incidents is not counted against you: the incident register then shows as unknown. Suppliers created from your cloud services don’t count until someone marks them assessed. A register whose entries haven’t been reviewed for a year counts only as declared, and an empty register doesn’t count at all. The same rule applies on the Security capabilities page, where the registers appear as Risk register, Supplier register, Training and awareness records, Policy acknowledgement, Incident register, Record of processing, Rights request log and Data protection impact assessments.

The Answers section of a risk shows which requirements a kept risk register helps answer in the frameworks you assess, such as ISO 27001, NIST CSF, NIS2, DORA, the NCA frameworks and SAMA.

A register shows that you identify and manage risk. It doesn’t show that any individual control works. That evidence still comes from your scans, directory sync and the rest of the platform.

Who can change a register

Admins and security leads can add, edit, review and delete entries. Viewers can see registers but not change them. Deleting a risk removes it from the register but keeps its history.