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: ___