Annexes and operational forms

Full name

_____________________________

Role / title

_____________________________

Onboarding date

_____________________________

Signature

_____________________________

Declaration

The undersigned declares:

• To have received, read and understood the NexStudio Code of Ethics in its current version.
• To commit to respecting its principles, rules of conduct and procedures.
• To have received or to receive according to the training plan the mandatory training on information security, privacy (PDPA and GDPR), sensitive data handling, responsible AI use and secure coding practices.
• To commit to reporting, in good faith and through the designated channels, any violations of the Code of which they become aware.
• To be aware that violation of the Code may result in proportionate disciplinary measures, up to termination of the contractual relationship.
• To accept that this declaration will be kept in their personnel file and used for corporate governance purposes.

1. Definition of Confidential Information

• "Confidential Information" means any data, information, document, know-how, source code, technical specification, business strategy, personal or sensitive data, communication or material — in any form (written, oral, electronic, visual) — that one party (the "Disclosing Party") communicates to the other (the "Receiving Party") in relation to the subject matter of the relationship, regardless of whether it is expressly marked as confidential.
• Confidential Information also includes personal data processed on behalf of the Controller, data relating to patients, clients and care recipients (for the Legal Tech and Health Tech perimeters), system logs, credentials and test and audit results.

2. Obligations of the Receiving Party

• Use Confidential Information exclusively for the agreed purposes and for the performance of the contractual relationship.
• Not disclose, copy, reproduce or distribute Confidential Information to third parties without prior written authorization from the Disclosing Party.
• Limit access to Confidential Information only to authorized persons who need to know and who are bound by confidentiality obligations at least equivalent.
• Adopt adequate technical and organizational security measures to protect Confidential Information from unauthorized access, loss, theft or disclosure.
• In case of sub-processing, request prior written authorization and impose equivalent contractual obligations on the sub-processor.

3. Exclusions

• Information already in the public domain without breach of this agreement.
• Information already in the Receiving Party's possession before disclosure, as documented.
• Information legitimately received from third parties without confidentiality obligations.
• Information that the Receiving Party is required to disclose by law or authority order (with prior notice to the Disclosing Party, where permitted).

4. Breach Notification

• The Receiving Party must notify the Disclosing Party of any unauthorized access, loss or disclosure of Confidential Information within 24 hours of discovery, providing: description of the event, data and categories of data involved, measures taken or proposed to mitigate the effects, contact point for information.

5. Duration and return

• The confidentiality obligation lasts for the entire duration of the relationship and for 5 years after its termination, unless longer legal obligations apply.
• Upon termination of the relationship, the Receiving Party must return or destroy all Confidential Information, providing written attestation.

6. Equivalent security measures

• Encryption at rest and in transit with up-to-date algorithms (minimum AES-256, TLS 1.3).
• Access control with least-privilege principle and mandatory MFA.
• Immutable logging for access to sensitive data.
• Documented incident management procedures.
• Staff training on security and privacy.

7. Governing law and jurisdiction

• Thai law, with possible reference to GDPR/PDPA clauses for personal data processing. Competent court: Bangkok, Thailand, unless otherwise agreed in writing.

Security

Code review completed and approved

[ ]

Automated tests passed (green CI)

[ ]

Static code analysis (SAST) with no critical or high vulnerabilities

[ ]

Dependency scan (SCA) with no known vulnerabilities with CVSS ≥ 7

[ ]

Penetration test or dynamic scan (DAST) performed on pre-release build

[ ]

No hardcoded credentials, tokens or secrets in the codebase

[ ]

HTTP security headers configured (HSTS, CSP, X-Frame-Options, etc.)

[ ]

CORS configured correctly (no wildcard on sensitive origins)

[ ]

Rate limiting active on public endpoints

[ ]

Dependencies updated to the latest stable version (or security patches applied)

[ ]

Privacy and data

No real personal data in test environments (only synthetic/anonymized data)

[ ]

Encryption at rest enabled for all sensitive data

[ ]

Encryption in transit (TLS 1.3) active on all endpoints

[ ]

Logging free of personal or sensitive data in cleartext

[ ]

Consent mechanisms verifiable and recorded (if applicable)

[ ]

Deletion/right to erasure procedures tested and working

[ ]

Retention policy implemented and verified

[ ]

DPIA updated for processing activities involved in the release

[ ]

Operations

Rollback plan documented and tested

[ ]

Changelog compiled with known impacts

[ ]

Notification to internal stakeholders (support, security, DPO)

[ ]

Monitoring and alerting configured for new features

[ ]

Signatures: Developer _______   Reviewer _______   CISO/DPO _______   Date _______

Flowchart: incident management phases

• 1. DETECTION — The incident is detected by: automatic monitoring system, internal report, bug bounty/external reporter, notification from a vendor or partner.
• 2. TRIAGE AND CLASSIFICATION (max 1 hour) — The security team assesses: incident type (data breach, unauthorized access, malware, DDoS, etc.), severity (low/medium/high/critical), perimeter involved (platform, Legal Tech, Health Tech), data involved (personal, sensitive, health, legal).
• 3. CONTAINMENT (immediate) — Isolate compromised systems, revoke exposed credentials or tokens, block malicious IPs or accounts, activate the designated response team.
• 4. ERADICATION — Remove root cause (patch, reconfiguration, malware removal), verify no backdoors or persistence, document actions taken.
• 5. RECOVERY — Restore systems from clean backups, apply patches and mitigations, validate operation in an isolated environment before returning to production.
• 6. NOTIFICATION — Within 72 hours of discovery: notify DPO and Legal & Compliance; if personal data breach, assess obligation to notify authority (PDPA/GDPR) and data subjects. Use the notification template (see below).
• 7. POST-MORTEM (within 5 working days) — Root cause analysis, lessons learned, security playbook and controls update, internal communication (non-blaming).

Incident notification template

To be sent internally and, if required, externally.

Incident ID

INC-YYYY-NNN

Detection date and time

_____________________

Containment date and time

_____________________

Severity

[ ] Low [ ] Medium [ ] High [ ] Critical

Type

[ ] Data breach [ ] Unauthorized access [ ] Malware [ ] DDoS [ ] Other: ___

Perimeter

[ ] Platform [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

Systems involved

_____________________

Data involved

Categories: ___ Estimated data subjects: ___

Description

_____________________

Actions taken

_____________________

Measures for data subjects

_____________________

Contact point

Name: ___ Email: ___ Phone: ___

Compiled by

_____________________

DPIA model — Required sections

1. Processing title

Brief description of the processing under assessment.

2. Controller and processors

Controller: ___ Processor(s): ___ Sub-processors: ___ DPO: ___

3. Purpose of processing

Describe why the data is processed, legal basis and necessity.

4. Data categories

[ ] Regular personal [ ] Special categories (health, legal, biometric) [ ] Criminal

5. Data subject categories

[ ] Patients [ ] Firm clients [ ] Employees [ ] Platform users [ ] Other: ___

6. Processing operations

Collection, recording, organization, storage, consultation, disclosure, erasure, etc.

7. Technologies used

Database, cloud, API, AI/ML, etc.

8. Risk assessment

Likelihood × Impact for each identified risk. Risk mitigation measures planned.

9. Security measures

Encryption, access control, logging, backup, etc.

10. DPO consultation

DPO opinion: ___ Date: ___

11. Final decision

[ ] Acceptable risk [ ] Risk mitigated [ ] Authority consultation needed [ ] Processing not to start

12. Date and signatures

Compiler: ___ DPO: ___ Controller: ___

Completed example — MediAura: clinical data management in the cloud

1. Title

Management and storage of clinical patient data on the MediAura platform (cloud, Bangkok).

2. Controller and processors

Controller: subscribing medical practice/clinic. Processor: NexStudio. Sub-processors: ISO 27001 certified cloud provider.

3. Purpose

Storage and consultation of clinical data to support medical practice. Legal basis: contract performance and patient consent (signed notice).

4. Data categories

Special categories: health data (diagnoses, prescriptions, reports). Regular personal: identity, contact details.

5. Data subjects

Patients (adults and minors via guardians).

6. Operations

Collection, recording, organization, storage, consultation by authorized staff, erasure on request.

7. Technologies

Encrypted database (AES-256), REST API with TLS 1.3, AI for clinical suggestions (human supervision mandatory).

8. Risks

Unauthorized access to health data (low likelihood, high impact → mitigated with MFA, encryption and audit log). Data loss (low likelihood, critical impact → mitigated with daily backups, tested disaster recovery).

9. Security measures

Encryption at rest AES-256 and in transit TLS 1.3. Mandatory MFA. Immutable logs. Automatic daily backup. Quarterly restore test.

10. DPO

Favorable opinion with recommendation for annual audit.

11. Decision

Risk mitigated — processing approved with annual review.

Personal data processing notice

Pursuant to PDPA (Thailand) and, where applicable, GDPR (EU).

Data Controller

[Firm/organization name], with office at [address], email: [___], phone: [___].

Data Processor (platform provider)

NexStudio, Bangkok, Thailand, email: privacy@nexstudio.com.

Processing purposes

Management of [legal/healthcare] services, document archiving, service-related communications, legal obligations.

Legal basis

[Data subject consent / Contract performance / Legal obligation / Legitimate interest].

Data categories

Identity and contact data. [Legal/healthcare] practice-related data. [If healthcare: health data pursuant to Art. 9 GDPR / PDPA].

Retention period

[X years] from the end of the relationship or as provided by the retention policy.

Data recipients

Authorized staff of the Controller. NexStudio (data processor). Cloud service providers (sub-processors with contractual guarantees). Public authorities, if required by law.

International transfers

[Describe if data is transferred outside Thailand/EU and on what legal basis].

Data subject rights

Access, rectification, erasure, restriction, portability, objection, consent withdrawal. To exercise rights, contact the Controller at the above address.

Complaints

The data subject has the right to lodge a complaint with the competent supervisory authority (PDPC in Thailand / Data Protection Authority in the EU).

Consent form

To be filled in and signed by the data subject.

• I, the undersigned _____________________, born on ____________,
• declare that I have received and read the personal data processing notice.
• [ ] I consent to the processing of my personal data for the purposes indicated in the notice.
• [ ] I consent to the processing of my special category data (e.g. health data / legal data) for the purposes indicated.
• [ ] I consent to the disclosure of my data to the parties indicated in the notice.
• Date: ____________   Signature: _____________________

Instructions

Fill in for each open source or third-party component used in the product. Update at every release.

• Generate automatically with tools such as: CycloneDX, SPDX, Syft, Trivy, OWASP Dependency-Track.
• The recommended format is CycloneDX JSON or SPDX tag-value.
• Below the template in tabular format for manual review.

Component inventory

Component name

Version | License | License type (copyleft/permissive) | Vendor/URL | Usage in product | Known vulnerabilities (CVE) | CVSS score | Last update date

Example first row: React | 18.3.1 | MIT | Permissive | https://react.dev | Frontend UI | None | N/A | 2026-04-01

Summary

Total components

___

Components with copyleft licenses

___ (verify compatibility)

Components with known vulnerabilities

___ (details above)

Components without declared license

___ (to be verified)

SBOM generation date

____________

Generated by

[Name] — [Role]

General principles

• Personal data is retained only for the time necessary to achieve the purposes for which it was collected.
• At the end of the retention period, data is anonymized or securely and irreversibly deleted.
• Retention periods are documented, justified and communicated to data subjects in the privacy notice.
• The policy is subject to review at least annually or upon regulatory changes.

Retention periods table

Identity and contact data

Period: 10 years from the end of the relationship (tax and legal obligations). Justification: Thai tax regulations. Deletion: anonymization at expiry.

Health data (MediAura / Health Tech)

Period: relationship duration + 10 years (or as per applicable local regulations). Justification: healthcare regulations, litigation, clinical needs. Deletion: secure destruction with certification.

Legal data / case files (LexAura / Legal Tech)

Period: relationship duration + 10 years. Justification: professional legal obligations, statute of limitations, litigation. Deletion: after verification with the firm controller.

Access logs and audit trail

Period: 2 years. Justification: security, investigations, compliance. Deletion: automatic rotation.

Billing data

Period: 10 years. Justification: tax and accounting obligations. Deletion: anonymization at expiry.

Data of non-hired candidates

Period: 12 months from application. Justification: possible future opportunities (with consent). Deletion: destruction at expiry.

Cookies and tracking data

Period: as per cookie policy (max 12 months). Justification: website analysis and functionality. Deletion: automatic expiry or on request.

Backups

Period: 30 days (operational backups), 12 months (historical backups). Justification: disaster recovery and business continuity. Deletion: automatic rotation. Personal data contained in backups is subject to the same retention periods and is deleted from the active backup at expiry.

Deletion methods

• Logical deletion: data is made inaccessible to the user but retained in a segregated area for the retention period.
• Physical deletion: at the end of the retention period, data is irreversibly overwritten or destroyed (crypto-shredding, degaussing, physical destruction for media).
• Anonymization: data is irreversibly transformed into anonymous form, not attributable to the data subject.
• For each deletion, documentary evidence is produced (log, certification).

General information

System/model name

_____________________

Version

_____________________

Perimeter

[ ] Platform [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

Technical owner

_____________________

Assessment date

_____________________

1. AI system description

• Describe the system purpose, functionalities, target users and context of use. Specify whether the system makes automated decisions or provides recommendations with human oversight.

2. Dataset and provenance

Training data sources

[ ] Internal data [ ] Public data [ ] Third-party data [ ] Synthetic data

Volume and characteristics

Number of records: ___ Features: ___ Class balance: ___

Quality and known limits

Describe any known bias, missing data, noise, labeling quality.

Pre-processing

Describe cleaning, normalization, feature engineering.

Privacy compliance

[ ] Anonymized data [ ] Consent obtained [ ] DPIA executed [ ] Legal basis documented

3. Bias assessment

• Describe the analyses conducted to identify and mitigate bias (demographic, cultural, gender, ethnic, etc.).
• Indicate fairness metrics used and results obtained.
• [object Object]
• [object Object]
• [object Object]

4. Human oversight

Automation level

[ ] Fully automated [ ] Human-in-the-loop [ ] Human-on-the-loop [ ] Recommendation only

Override mechanism

How can the user override the system's decision?

Warnings and limitations

What warnings are shown to the user about the system's limits?

5. Explainability and transparency

Explainability method

[ ] SHAP [ ] LIME [ ] Feature importance [ ] Attention maps [ ] Other: ___

User documentation

Describe how decisions are explained to the end user.

Limitations communicated

How are limits, accuracy and error margins communicated?

6. Post-release monitoring

Metrics monitored

Accuracy, precision, recall, F1, drift detection, fairness metrics, latency.

Monitoring frequency

[ ] Continuous [ ] Daily [ ] Weekly [ ] Monthly

Alerting

Alert thresholds defined for drift and performance degradation.

Rollback plan

Procedure to deactivate or replace the model in case of unexpected or harmful behavior.

7. Risk assessment

Impact on fundamental rights

[ ] Low [ ] Medium [ ] High — explain: ___

Impact on health or safety

[ ] None [ ] Potential [ ] Direct — explain: ___

Discrimination risk

[ ] Low [ ] Medium [ ] High — explain: ___

Opacity risk

[ ] Low [ ] Medium [ ] High — explain: ___

8. Approval

Compiler

Name: ___ Signature: ___ Date: ___

CTO / Technical lead

Name: ___ Signature: ___ Date: ___

DPO / Privacy lead

Name: ___ Signature: ___ Date: ___

Legal & Compliance

Name: ___ Signature: ___ Date: ___

Ethics committee (if applicable)

Opinion: ___ Date: ___

1. Objectives

• Ensure every collaborator knows the Code of Ethics, security and privacy duties, and role limits on data (platform, Legal Tech, Health Tech).
• Reduce operational and regulatory risk in the first 90 days and keep skills current with an annual refresh.
• Produce documentary evidence (attestations, quizzes, register) for audits and training-completion KPIs.

2. Audience and responsibilities

All collaborators

Founders, employees, consultants and contractors with access to NexStudio systems or data.

Plan owner

HR (calendar, register, reminders).

Content owners

CISO (security), DPO (privacy), Legal (Code of Ethics / compliance), CTO (secure coding / AI).

Line managers

Verify completion by deadlines and report delays to HR.

3. Mandatory modules (core)

M1 — Code of Ethics and conduct

Duration: 1.5 h. Contents: values, conflicts of interest, reporting, sanctions. Output: signed adhesion declaration.

M2 — Information security

Duration: 2 h. Contents: phishing, password/MFA, data classification, device handling, incident reporting. Output: quiz ≥ 80%.

M3 — Privacy PDPA and GDPR

Duration: 2 h. Contents: legal bases, data subject rights, transfers, 72h breach notification, controller/processor roles. Output: quiz ≥ 80%.

M4 — Sensitive data and product perimeters

Duration: 1.5 h. Contents: LexAura (professional secrecy), MediAura (health data), minimization, privileged access. Output: signed understanding checklist.

M5 — Responsible AI/ML use

Duration: 1.5 h. Contents: bias, human oversight, model limits, prohibition of incompatible uses. Output: quiz ≥ 80%.

M6 — Secure coding and release (technical roles)

Duration: 2 h. Contents: OWASP top risks, secret management, pre-release checklist, SBOM. Mandatory for developers, DevOps, QA. Output: quiz ≥ 80% + checklist exercise.

4. 90-day onboarding calendar

Day 0–7 (week 1)

M1 Code of Ethics + signed adhesion and NDA if applicable. System access only after MFA and basic security briefing (M2 excerpt).

Day 8–30 (month 1)

Full M2 Security + M3 Privacy. No production data access without completed M2/M3.

Day 31–60 (month 2)

M4 Product perimeters (LexAura/MediAura by role) + M5 AI. Technical roles: start M6.

Day 61–90 (month 3)

Complete M6 (if required). Manager review: gaps, extra training, register confirmation. HR checkpoint: 100% role-mandatory modules.

Hard deadlines: adhesion within 7 days; core M2–M5 within 60 days; M6 within 90 days for technical roles. Delays > 14 days: escalate to HR and manager; access may be limited.

5. Annual recurring training

• Mandatory refresh within 12 months of previous completion (or onboarding date).
• Minimum aggregate duration: 3 hours (updated M1 + M2/M3 regulatory deltas + AI reminder).
• Additional triggers: material regulatory change, major incident, new product perimeter, critical role change.
• Allowed formats: live session, async e-learning with quiz, or documented internal workshop.

6. Extra training for critical roles

CISO / security

Incident response playbook, annual tabletop, threat modeling.

DPO / privacy

DPIA workshop, data subject rights, international transfers.

Legal & compliance

LexAura/MediAura regulatory updates, sub-processor contracts.

Engineering / DevOps

Advanced secure SDLC, SBOM review, penetration test findings walkthrough.

Support / customer success

Least privilege on customer data, escalation scripts, no use outside tickets.

7. Delivery and materials

• Languages: Italian, English, Thai (aligned with the site and Code of Ethics).
• Materials: internal slides/videos, current Code of Ethics, operational annexes (checklist, DPIA, AI impact).
• Assessment: multiple-choice quiz (80% threshold) or attendance attestation + exercise for workshops.
• Retake: if quiz fails, retry within 14 days with domain-owner tutoring.

8. Training register (row template)

Mandatory fields per record

Collaborator name | Role | Module (M1–M6 / annual / critical) | Date | Duration (h) | Result (passed / retake) | Evidence (quiz link / PDF / signature) | Verification owner

Register retention: aligned with the retention policy (training records and adhesion declarations). Recommended format: shared sheet or HRIS with audit export.

9. KPIs and control

• % onboarding with mandatory modules completed within 90 days (target ≥ 95%).
• % staff with annual refresh in good standing (target ≥ 95%).
• Average completion time for M1–M5.
• Number of delays > 14 days and corrective actions.

1. Purpose

• Allow researchers and users to report vulnerabilities in good faith, with defined response times and without legal risk if they follow this policy.
• Protect customer, patient and firm data (LexAura / MediAura) and SaaS availability.

2. Scope (in scope)

• Public NexStudio websites and web apps (main domain and IT/EN/TH subpages).
• Authenticated APIs and endpoints of LexAura and MediAura exposed in production or public staging.
• Cloud infrastructure directly attributable to NexStudio and reachable from the Internet.
• Misconfigurations exposing personal data, secrets, backups or admin panels.

3. Out of scope

• DoS/DDoS, flooding, uncoordinated stress tests.
• Social engineering of employees, customers or vendors (phishing, pretexting).
• Spam, malware delivery, physical security.
• Vulnerabilities in third-party products not operated by NexStudio, unless caused by our misconfiguration.
• Scanner-only reports without a reproducible PoC.
• Findings already known and in remediation.

4. Good-faith testing rules

• Do not access, modify or delete third-party data beyond what is strictly needed to demonstrate the issue.
• Stop immediately if real personal or health data is encountered; report without exfiltrating.
• Do not run exploits that degrade service or compromise other users.
• Do not demand ransom or disclose publicly before coordination (reasonable embargo).
• Use your own test accounts or staging environments when available.

5. How to report

Channel

Email: security@nexstudio.com (optional PGP later, if published).

Minimum report contents

Short title | URL / endpoint / component | Description and impact | Reproduction steps (PoC) | Estimated severity (Low/Medium/High/Critical) | Follow-up contact | If data was seen: categories and volume (do not attach the data itself)

Suggested subject: [SECURITY] short title. Do not attach dumps of real data.

6. Response and remediation SLAs

Ack (receipt)

Within 72 business hours of a valid report.

Initial triage

Within 5 business days: in/out of scope and preliminary severity.

Indicative fix targets

Critical: immediate containment; fix or mitigation within 7 days | High: 14 days | Medium: 30 days | Low: 90 days or next release cycle

Communication

Updates to the reporter until closure; optional public advisory after fix, with credit if requested.

7. Safe harbor

• NexStudio will not pursue legal action against good-faith reporters who follow this policy and applicable law.
• Safe harbor does not cover out-of-scope activity, data theft, extortion or intentional harm.

8. Recognition and bug bounty

• Current phase (soft bounty): written thanks and, if the reporter agrees, mention in a hall of fame / advisory.
• Cash or swag rewards: not guaranteed; may be introduced later with a public grid without changing the security@ channel.
• Duplicates and out-of-scope: polite ack without reward.

9. Internal owners

CISO / Security

Triage, remediation, reporter communication.

DPO

Involved if the issue implies personal data or a breach.

Legal

Safe harbor assessment and public disclosure.

CTO

Technical priority and fix resources.

1. Common principles

• Register owner: named role (DPO, CISO, CTO or Legal) with a backup.
• Updates: on every new processing / incident / release / material deletion; periodic review at least quarterly.
• Retention: aligned with the retention policy; export available for authorities and audits.
• Format: one row = one record; unique ID; last-updated date mandatory.

2. Records of processing (RoPA / GDPR Art. 30 / PDPA)

Row fields

Processing ID (e.g. TRT-001) | Name / description | Perimeter (platform / LexAura / MediAura) | Controller | Processor / sub-processors | Data subject categories | Data categories (regular / special) | Purposes | Legal basis | Transfers outside TH/EU (Yes/No + tool) | Security measures (ref.) | Retention (policy ref.) | DPIA (Yes/No + link) | Owner | Last update

For high-risk processing: link DPIA ID from the DPIA model annex. Do not put data subjects’ personal data in the register.

3. Incident and data-breach register

Row fields

Incident ID (INC-YYYY-NNN) | Detection date/time | Containment date/time | Severity | Type (data breach / unauthorized access / malware / other) | Perimeter | Systems involved | Data categories / estimated data subjects | Authority notification (Yes/No/N.A. + date) | Data subject notification (Yes/No/N.A. + date) | Status (open / in progress / closed) | Root cause (summary) | Corrective actions | Owner | Post-mortem link

Use the incident notification template from the incident-management annex as an attachment to the record.

4. SBOM / component inventory register (operational)

Row fields (per release or critical component set)

Release ID / commit | Product (platform / LexAura / MediAura) | SBOM generation date | Format (CycloneDX / SPDX) | SBOM artifact link | Component count | Open vulns (CVSS ≥ 7) | Copyleft licenses / IP review | Technical owner | Pre-release gate result (OK / blocked) | Notes

Component detail stays in the SBOM file; this register tracks generations and gates. Align with the pre-release checklist.

5. Retention and deletion register

Row fields

Job ID (RET-001) | Data category (retention policy ref.) | System / datastore | Retention period applied | Trigger (expiry / data subject request / end of contract) | Action (anonymization / logical / physical deletion) | Execution date | Evidence (log / ticket / certificate) | Records affected (aggregate) | Executor | DPO/CISO verification (date)

Do not list data subject identifiers; aggregates and technical refs only. Align with the retention policy annex.

6. Vendor and sub-processor register (minimum)

Row fields

Vendor ID | Name / service | Role (sub-processor / vendor) | Data processed (categories) | Location / transfers | DPA / NDA (link + signature date) | Equivalent security measures (Yes/No) | Review date | Legal owner | Status (active / exiting / terminated)

7. Owners and KPIs

Processing + DPIA register

DPO (backup: Legal)

Incident register

CISO (backup: CTO)

SBOM register

CTO / engineering lead

Retention register

DPO + engineering

Sub-processor register

Legal (backup: DPO)

Sample KPIs

% processings with owner and update < 90 days | Open incidents past SLA | Releases without SBOM = 0 | Retention jobs run vs planned