GDPR Compliance

MazeVault Data Protection Framework under Regulation (EU) 2016/679

Document ID: MV-LEG-022
Version: 1.0.0
Classification: Internal
Owner: Data Protection Officer (DPO)
Last Updated: 2026-05-01
Review Cycle: Annual
Approved By: CEO / Board of Directors

---

1. Purpose and Scope

This document defines MazeVault's compliance framework with the General Data Protection Regulation (EU) 2016/679 ("GDPR"). It establishes the data protection principles, technical measures, and organizational controls implemented within the MazeVault platform to ensure lawful processing of personal data.

1.1 MazeVault's Role as Data Processor

MazeVault acts as a Data Processor within the meaning of Article 28 GDPR. The Customer deploying MazeVault is the Data Controller and retains full authority over the purposes and means of processing personal data within the platform.

MazeVault processes personal data solely on behalf of and under the documented instructions of the Controller. MazeVault does not determine the purposes or means of processing, does not use Customer data for its own purposes, and does not share Customer data with third parties except as instructed by the Controller or required by applicable law.

1.2 Scope of Application

This framework applies to:

• All personal data processed by MazeVault platform components
• All MazeVault personnel with access to systems processing personal data
• All environments (production, staging, development) where personal data may be present
• All deployment models (cloud-hosted, on-premise, hybrid)

1.3 Legal Basis

• Regulation (EU) 2016/679 (General Data Protection Regulation)
• Act No. 110/2019 Coll. on the Processing of Personal Data (Czech Republic)
• Applicable national implementations of GDPR in Customer jurisdictions

---

2. Data Processing Role

2.1 Processing Scope

MazeVault processes personal data ONLY as instructed by the Customer (Controller). The Processor does not independently determine what personal data is collected, how long it is retained, or to whom it is disclosed. All such decisions remain with the Controller.

2.2 Categories of Personal Data Processed

The following categories of personal data are processed within the MazeVault platform:

User Account Data

Data Element	Purpose	Storage Location
Username	Authentication, identification	User database
Email address	Authentication, notifications	User database
Password hash (bcrypt/argon2)	Authentication	User database
MFA seed (TOTP)	Multi-factor authentication	Encrypted in user database

Access Logs

Data Element	Purpose	Storage Location
IP address	Security monitoring, access control	Audit log database
User agent string	Security monitoring, anomaly detection	Audit log database
Session identifiers	Session management	Session store

Audit Trail

Data Element	Purpose	Storage Location
User actions (CRUD operations)	Compliance, accountability	Audit log database
Timestamps	Temporal correlation	Audit log database
Resource identifiers	Action context	Audit log database

Customer Secrets

Customer secrets MAY contain personal data (e.g., connection strings with usernames, API keys associated with individuals). However, MazeVault cannot access the plaintext of stored secrets due to:

• Encryption at rest: All secrets encrypted with AES-256-GCM before storage
• Zero-Knowledge mode (V2): Server-side components never possess decryption keys
• Orchestrator mode: Secret values stored in Customer's external KV store, not within MazeVault

The Controller is responsible for determining whether secrets contain personal data and ensuring appropriate legal basis for such processing.

2.3 Processing Instructions

The Controller's processing instructions are documented in:

• The Data Processing Agreement (MV-LEG-031)
• The Master Service Agreement (MSA)
• Any additional written instructions provided by the Controller

MazeVault shall immediately inform the Controller if, in its opinion, an instruction infringes GDPR or other Union or Member State data protection provisions (Art. 28(3)).

---

3. Records of Processing Activities (RoPA)

Pursuant to Article 30(2) GDPR, MazeVault maintains the following records of processing activities carried out on behalf of Controllers:

3.1 Processing Activities Register

Processing Activity	Categories of Data	Data Subjects	Purpose	Legal Basis	Retention	Recipients
User authentication	Username, email, password hash, IP address, MFA seeds	Customer employees and contractors	Platform access control and identity verification	Contract performance (Art. 6(1)(b))	Account lifetime (until Controller requests deletion)	None (internal processing only)
Audit logging	user_id, IP address, user_agent, actions performed, timestamps	Customer employees and contractors	Security monitoring, compliance demonstration, accountability	Legitimate interest (Art. 6(1)(f)) — security of processing	365 days (configurable per Controller instruction)	Customer SIEM (if configured by Controller)
Secret storage	encrypted_value (not readable by MazeVault), metadata (key name, project, tags)	May include data subjects' personal data (Controller determines)	Secrets management per Controller instruction	Contract performance (Art. 6(1)(b))	Customer-defined (until Controller deletes)	None (encrypted, inaccessible to Processor)
Certificate management	Common Name (CN), Subject Alternative Names (SAN) — may include personal names or email addresses	Certificate subjects (employees, services, devices)	PKI management, certificate lifecycle operations	Contract performance (Art. 6(1)(b))	Certificate lifetime + 1 year (for revocation verification)	CA providers (CSR submission as instructed by Controller)
License management	Organization name, administrator email address	Customer administrator	License activation and compliance verification	Contract performance (Art. 6(1)(b))	License lifetime	License server (maze-admin internal service)

3.2 Record Maintenance

• Records are maintained in electronic form and available to supervisory authorities upon request
• Records are reviewed and updated at minimum annually or upon significant changes to processing
• The DPO is responsible for accuracy and completeness of records

---

4. Data Protection Impact Assessment (DPIA)

Pursuant to Article 35 GDPR, MazeVault has conducted a Data Protection Impact Assessment for its processing activities. The following is a summary of the DPIA findings:

4.1 Nature of Processing

• Storing and managing encrypted secrets and credentials on behalf of Controllers
• Certificate lifecycle management including issuance, renewal, and revocation
• User authentication and authorization for platform access
• Audit logging of all user actions for compliance and security purposes

4.2 Scope of Processing

• Limited to Customer-designated data only
• All sensitive data encrypted at rest (AES-256-GCM)
• Processing restricted to Controller's documented instructions
• No large-scale processing of special categories of data (Art. 9)
• No systematic monitoring of publicly accessible areas

4.3 Context of Processing

• Enterprise secrets management for regulated entities (financial, healthcare, government)
• High-security environment with defense-in-depth architecture
• Customers in regulated industries requiring strict data protection controls
• Processing occurs within Customer-controlled infrastructure (on-premise) or designated cloud regions

4.4 Risk Assessment

Risk	Likelihood	Impact	Mitigation	Residual Risk
Data breach (unauthorized access to secrets)	Low	Critical	AES-256-GCM encryption, RBAC, MFA, audit logging, HSM support	Very Low
Unauthorized disclosure of personal data in logs	Low	High	Pseudonymization (user_id), log access controls, retention limits	Low
Loss of availability (service outage)	Medium	Medium	Multi-DC architecture, automated failover, backup/restore	Low
Insider threat	Low	High	Least privilege (RBAC), audit logging, segregation of duties, personnel security (organizational HR policy)	Low
Supply chain compromise	Low	High	SBOM, dependency scanning, CI/CD pipeline integrity, vendor assessment	Low

4.5 Necessity and Proportionality

• Data minimization: Only essential data stored; no collection beyond what is necessary for service delivery
• Purpose limitation: Data processed only for documented purposes (secrets management, PKI, authentication)
• Storage limitation: Retention periods defined and enforced; automatic deletion where configured
• Accuracy: User profile data editable by Controller; automated certificate expiry tracking

4.6 Measures to Address Risks

Measure	GDPR Reference	Implementation
Encryption at rest	Art. 32(1)(a)	AES-256-GCM for all sensitive data
Encryption in transit	Art. 32(1)(a)	TLS 1.2+ (TLS 1.3 preferred)
Access control	Art. 32(1)(b)	RBAC with least privilege, MFA, SSO
Audit logging	Art. 5(2)	Chain-hashed immutable audit trail
Incident response	Art. 33, 34	Formal IRP with <24h notification
Key management	Art. 32(1)(a)	HSM-backed, automated rotation
Regular testing	Art. 32(1)(d)	Pen-testing, vulnerability scanning, DR tests
Privacy by design	Art. 25	Zero-knowledge architecture, data minimization

4.7 DPIA Conclusion

The assessment concludes that, with the implemented technical and organizational measures, the residual risk to data subjects' rights and freedoms is acceptable. No prior consultation with the supervisory authority (Art. 36) is required.

---

5. Data Subject Rights

MazeVault, as Processor, assists the Controller in fulfilling data subject rights requests pursuant to Article 28(3)(e). The following describes the technical capabilities available to support each right:

5.1 Right of Access (Article 15)

Controller obligation: Provide data subjects with a copy of their personal data and information about processing.

MazeVault support:

• Audit log search by user identifier (returns all logged actions for a data subject)
• User data export (account information, associated roles, permissions)
• Access log retrieval (IP addresses, login history, session data)
• API endpoint: GET /api/v1/users/{id}/export

5.2 Right to Rectification (Article 16)

Controller obligation: Rectify inaccurate personal data without undue delay.

MazeVault support:

• User profile editing (username, email, display name)
• Certificate subject modification (reissuance with corrected data)
• Admin API for bulk corrections
• API endpoint: PUT /api/v1/users/{id}

5.3 Right to Erasure (Article 17)

Controller obligation: Erase personal data when grounds apply (consent withdrawn, no longer necessary, etc.).

MazeVault support:

• Account deletion (removes user record, deactivates sessions)
• Secret deletion (removes encrypted values and metadata)
• Certificate revocation and removal
• Audit log consideration: logs containing user_id may be retained for legitimate security interests (Art. 17(3)(b)) — Controller determines retention
• API endpoint: DELETE /api/v1/users/{id}

Audit Log Retention

Audit logs serve a legitimate interest in security and compliance. Erasure of audit records may conflict with regulatory obligations. The Controller must balance erasure requests against security and compliance requirements.

5.4 Right to Restriction of Processing (Article 18)

Controller obligation: Restrict processing in specified circumstances (accuracy contested, unlawful processing, etc.).

MazeVault support:

• Account suspension (user cannot authenticate, data preserved)
• Role revocation (access removed, account maintained)
• Project-level access restriction
• API endpoint: POST /api/v1/users/{id}/suspend

5.5 Right to Data Portability (Article 20)

Controller obligation: Provide personal data in structured, commonly used, machine-readable format.

MazeVault support:

• User data export in JSON format
• Secrets export in JSON format (encrypted or plaintext per Controller authorization)
• Certificate export in standard formats: PEM, DER, PKCS#12
• Bulk export via API or CLI tooling
• API endpoint: GET /api/v1/export

5.6 Right to Object (Article 21)

Not applicable: MazeVault does not perform profiling, direct marketing, or processing based on legitimate interest for its own purposes. All processing is performed on behalf of and as instructed by the Controller.

5.7 Response Procedure

1. Controller receives data subject request
2. Controller validates identity of data subject
3. Controller instructs MazeVault via support channel or API
4. MazeVault executes technical measures within 5 business days
5. MazeVault confirms completion to Controller
6. Controller responds to data subject within statutory timeframe (1 month)

---

6. Data Breach Notification (Articles 33 and 34)

6.1 Processor Notification to Controller

MazeVault shall notify the Controller of a personal data breach without undue delay and in any event within 24 hours of becoming aware of the breach.

The notification shall include:

Information	Description
Nature of the breach	Type (confidentiality, integrity, availability), attack vector
Categories of data affected	User accounts, audit logs, secrets, certificates
Approximate number of data subjects affected	Count or estimate
Approximate number of records affected	Count or estimate
Likely consequences	Risk assessment for data subjects
Measures taken or proposed	Immediate response, remediation, prevention
Contact point	DPO or designated security contact

6.2 Controller Obligations

The Controller is responsible for:

• Notifying the competent Data Protection Authority (DPA) within 72 hours of becoming aware of the breach (Art. 33(1))
• Assessing whether the breach is likely to result in a high risk to data subjects
• Notifying affected data subjects without undue delay where high risk exists (Art. 34(1))
• Documenting the breach regardless of whether notification to DPA is required (Art. 33(5))

6.3 Cooperation

MazeVault shall:

• Cooperate fully with the Controller's investigation
• Preserve all relevant evidence (minimum 3 years)
• Provide additional information as it becomes available
• Assist the Controller in communicating with the DPA
• Implement immediate containment measures
• Conduct root cause analysis and provide report within 14 days

6.4 Breach Classification

Classification	Criteria	Notification Required
Confirmed breach	Personal data confirmed accessed/disclosed/lost	Yes — within 24 hours
Suspected breach	Indicators of compromise, investigation ongoing	Yes — preliminary notification within 24 hours, confirmed within 72 hours
Near miss	Attempted breach, no data compromised	No notification required; documented internally

---

7. Technical and Organizational Measures (TOMs)

Pursuant to Article 32 GDPR, MazeVault implements the following technical and organizational measures to ensure a level of security appropriate to the risk:

7.1 Pseudonymization (Art. 32(1)(a))

• Internal logs reference user_id (UUID) rather than personal identifiers (name, email)
• Correlation between user_id and personal data restricted to user database with access controls
• Audit logs can be provided without revealing personal identity (pseudonymized export)
• Certificate serial numbers used instead of subject names in operational logs

7.2 Encryption (Art. 32(1)(a))

Layer	Method	Standard
Data at rest (secrets)	AES-256-GCM	NIST SP 800-38D
Data at rest (database)	AES-256 (transparent encryption)	Provider-specific
Data in transit (external)	TLS 1.2+ (TLS 1.3 preferred)	RFC 8446
Data in transit (internal)	mTLS between services	X.509 certificates
Key encryption keys	RSA-4096 or AES-256-KW	NIST SP 800-56B
Backup encryption	AES-256-GCM	NIST SP 800-38D

7.3 Confidentiality (Art. 32(1)(b))

• Role-Based Access Control (RBAC) with principle of least privilege
• Project isolation (users cannot access projects they are not assigned to)
• Domain separation (organizational boundaries enforced)
• Multi-factor authentication (TOTP-based MFA)
• Single Sign-On integration (OIDC, SAML 2.0, LDAP/AD)
• Automatic session timeout and re-authentication
• Personnel security per organizational HR policy of MazeVault s.r.o.

7.4 Integrity (Art. 32(1)(b))

• Chain-hashed audit logs (SHA-256) — tamper detection
• Database integrity constraints (foreign keys, unique constraints, check constraints)
• Input validation on all API endpoints
• Digital signatures on certificates and artifacts
• Checksums on backup files
• Version control on all configuration changes

7.5 Availability (Art. 32(1)(b))

• Multi-datacenter deployment with geographic redundancy
• Automated backup and restore procedures
• Disaster recovery with documented failover procedures
• Load balancing and horizontal scaling
• Database replication (synchronous for critical data)
• Redundant network paths

7.6 Resilience (Art. 32(1)(b))

• Circuit breakers preventing cascade failures
• Health monitoring with automated alerting
• Auto-restart of failed services (Kubernetes liveness/readiness probes)
• Graceful degradation under load
• Rate limiting to prevent resource exhaustion
• Queue-based processing for async operations

7.7 Regular Testing (Art. 32(1)(d))

Test Type	Frequency	Scope
Penetration testing	Annual (minimum)	Full application and infrastructure
Vulnerability scanning	Per build (CI/CD)	Application dependencies and containers
DR testing	Quarterly	Full failover and recovery
Backup restoration	Quarterly	Database and configuration
Security awareness (organizational)	Ongoing	MazeVault s.r.o. personnel
Tabletop exercises	Semi-annual	Incident response scenarios

7.8 Ability to Restore (Art. 32(1)(c))

• Automated daily backups (configurable frequency)
• Backup encryption (AES-256-GCM)
• Off-site backup storage (geographically separated)
• Documented recovery procedures with defined RTO/RPO
• Regular restoration testing (quarterly verification)
• Point-in-time recovery capability (database WAL)

---

8. Sub-processing (Articles 28(2) and 28(4))

8.1 General Authorization

MazeVault engages sub-processors only with the prior written authorization of the Controller, as specified in the Data Processing Agreement (MV-LEG-031).

8.2 Sub-processor List

The current list of authorized sub-processors is maintained in the Subprocessor List (MV-LEG-033). This list includes:

• Sub-processor name and contact
• Processing activities performed
• Location of processing
• Categories of data processed
• Safeguards implemented

8.3 New Sub-processor Engagement

When MazeVault intends to engage a new sub-processor:

1. 30-day advance notification to Controller (via email to designated contact)
2. Notification includes: sub-processor identity, processing description, location, safeguards
3. Controller has 15 business days to raise objection
4. If Controller objects with reasonable grounds, MazeVault shall not engage the sub-processor for that Controller's data
5. If no objection received within 15 business days, authorization is deemed granted

8.4 Sub-processor Obligations

Each sub-processor is bound by a written agreement imposing:

• The same data protection obligations as in the Controller-Processor agreement
• Appropriate technical and organizational measures (Art. 32)
• Assistance with data subject rights
• Notification of breaches
• Audit rights

8.5 Processor Liability

MazeVault remains fully liable to the Controller for the performance of the sub-processor's obligations. Where a sub-processor fails to fulfill its data protection obligations, MazeVault shall be liable to the Controller for the sub-processor's performance.

---

9. International Data Transfers

9.1 Default Processing Location

By default, all personal data processed by MazeVault remains within:

• On-premise deployments: Customer's own infrastructure within their chosen jurisdiction
• Cloud deployments: Customer-specified Azure region (EU regions available: West Europe, North Europe, Germany West Central)

9.2 Transfer Mechanisms

Where international data transfers are necessary:

Destination	Data Type	Transfer Mechanism	Safeguard
EU/EEA	All	No transfer mechanism required	Adequate protection under GDPR
GitHub (USA)	Source code only	Standard Contractual Clauses (Module 3)	No customer personal data transferred
Customer-designated regions	As instructed by Controller	Controller's responsibility	Controller determines adequacy

9.3 Restrictions

• No transfer to countries without an adequacy decision (Art. 45) unless appropriate safeguards are in place (Art. 46)
• Standard Contractual Clauses (SCCs) as adopted by Commission Implementing Decision (EU) 2021/914 applied where required
• Transfer Impact Assessments conducted for non-adequate jurisdictions
• Customer data is never transferred for MazeVault's own purposes

9.4 Customer Control

The Controller retains full control over data location:

• Choice of deployment model (on-premise eliminates any transfer)
• Choice of cloud region
• Configuration of replication targets
• Approval required for any change in processing location

---

10. Data Retention and Deletion

10.1 Retention Periods

Data Category	Retention Period	Basis	Deletion Method
Audit logs	365 days (default, configurable)	Legitimate interest (security)	Automatic archival/deletion
User accounts	Until Controller requests deletion	Contract	Manual deletion via API
Secrets	Until Controller deletes	Contract (Controller instruction)	No automatic deletion
Certificates	Certificate lifetime + 1 year	Contract (revocation verification)	Automatic after retention
Session data	24 hours after expiry	Technical necessity	Automatic cleanup
Backup data	90 days (default, configurable)	Contract (recovery)	Automatic rotation

10.2 Contract Termination

Upon termination of the service agreement:

1. Data return: Controller may export all data in standard formats (JSON, PEM, PKCS#12, CSV) within 30 days of termination
2. Secure deletion: All personal data securely deleted within 90 days of termination (or upon Controller instruction, whichever is earlier)
3. Deletion method: Cryptographic erasure (key destruction) and/or multi-pass overwrite per NIST SP 800-88
4. Confirmation: Written confirmation of deletion provided to Controller, signed by DPO
5. Exceptions: Data may be retained where required by applicable law (e.g., tax records, legal holds) — Controller notified of such retention

10.3 Deletion Verification

• Deletion operations are logged in the audit trail
• Annual review of retained data against retention schedule
• Automated alerts for data approaching retention limits
• Quarterly verification that deletion processes are functioning correctly

---

11. Privacy by Design and Default (Article 25)

11.1 Privacy by Design Principles

MazeVault incorporates data protection principles into the design of the platform from inception:

Principle	Implementation
Proactive not reactive	Security and privacy built into architecture, not bolted on
Privacy as default	No access without explicit role assignment; encryption by default
Privacy embedded in design	Zero-knowledge architecture; data minimization in schema design
Full functionality	Security without sacrificing usability
End-to-end security	Protection throughout the data lifecycle
Visibility and transparency	Comprehensive audit logging; open documentation
Respect for user privacy	Data minimization; purpose limitation; user control

11.2 Zero-Knowledge Architecture (V2)

In Zero-Knowledge mode:

• The server never possesses decryption keys for customer secrets
• Encryption/decryption occurs client-side (in the agent or CLI)
• Server stores only ciphertext and metadata
• Even a complete server compromise does not expose plaintext secrets
• MazeVault cannot comply with demands to produce plaintext (technical impossibility)

11.3 Orchestrator Mode

In Orchestrator mode:

• Secret values are stored in the Customer's external Key-Value store (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager)
• MazeVault stores only references (pointers) to external values
• No personal data within secrets is stored on MazeVault infrastructure
• Customer retains direct control over secret storage and lifecycle

11.4 Data Minimization

• Only essential metadata stored (key name, project, domain, timestamps)
• No collection of personal data beyond what is strictly necessary
• User profiles limited to authentication-required fields
• Logs contain pseudonymized identifiers (user_id, not names)
• No behavioral tracking, analytics, or profiling

11.5 Encryption by Default

• All secrets encrypted before storage (no opt-out)
• All network communication encrypted (TLS enforced)
• Backup encryption mandatory
• Database encryption at rest enabled by default

11.6 Access by Default

• No user has access to any resource without explicit role assignment
• New users have zero permissions until assigned by an administrator
• Projects are isolated by default (no cross-project visibility)
• Principle of least privilege enforced at all levels

---

12. Compliance Mapping

The following table maps GDPR articles to MazeVault's implementation:

GDPR Article	Requirement	MazeVault Implementation	Evidence
Art. 5(1)(a)	Lawfulness, fairness, transparency	Processing only on Controller instruction; transparent documentation	DPA, this document
Art. 5(1)(b)	Purpose limitation	Data used only for documented purposes	RoPA (Section 3)
Art. 5(1)(c)	Data minimization	Only essential data collected	Schema design, Section 11.4
Art. 5(1)(d)	Accuracy	User profile editing; certificate lifecycle management	API documentation
Art. 5(1)(e)	Storage limitation	Defined retention periods; automatic deletion	Section 10
Art. 5(1)(f)	Integrity and confidentiality	Encryption, access control, audit logging	TOMs (Section 7)
Art. 5(2)	Accountability	Comprehensive audit trail; documentation	Audit logs, this document
Art. 6	Lawful basis	Controller determines; MazeVault processing based on contract	DPA (MV-LEG-031)
Art. 12-22	Data subject rights	Technical support for all applicable rights	Section 5
Art. 24	Controller responsibility	Controller guidance documentation; DPA clarity	DPA, MSA
Art. 25	Privacy by design/default	Zero-knowledge, encryption by default, minimization	Section 11
Art. 28	Processor obligations	DPA, documented instructions, cooperation	MV-LEG-031
Art. 30	Records of processing	RoPA maintained and updated	Section 3
Art. 32	Security of processing	TOMs implemented and tested	Section 7
Art. 33	Breach notification to DPA	24h notification to Controller	Section 6
Art. 34	Breach notification to subjects	Assistance to Controller	Section 6
Art. 35	DPIA	DPIA conducted and documented	Section 4
Art. 44-49	International transfers	Default EU; SCCs where required	Section 9

---

13. Related Documents

Document ID	Title	Relevance
MV-LEG-001	Information Security Policy	Overarching security framework
MV-LEG-003	Access Control Policy	RBAC implementation details
MV-LEG-004	Cryptography Policy	Encryption standards and key management
MV-LEG-005	Data Classification and Retention Policy	Data handling and retention rules
MV-LEG-007	Incident Response Plan	Breach response procedures
MV-LEG-008	Business Continuity and Disaster Recovery	Availability and resilience
MV-LEG-030	Security Annex Template	Contractual security measures
MV-LEG-031	Data Processing Agreement	Art. 28 DPA template
MV-LEG-032	SLA/OLA Framework	Service availability commitments
MV-LEG-033	Subprocessor List	Authorized sub-processors

---

Document Control

Version	Date	Author	Changes
1.0.0	2026-05-01	DPO	Initial release

---

This document is reviewed annually or upon significant changes to processing activities, regulatory requirements, or organizational structure. The DPO is responsible for maintaining this document and ensuring its accuracy.