BEYOĞLU PROFESSIONAL SECURITY AND TECHNICAL & ORGANISATIONAL MEASURES ANNEX

BEYOĞLU PROFESSIONAL SECURITY AND TECHNICAL & ORGANISATIONAL MEASURES ANNEX

GDPR Articles 28 and 32 — Technical and Organisational Measures

Version: 1.0
Effective Date: 1 October 2026

This Annex describes the technical and organisational safeguards maintained or contractually required for the Beyoğlu Professional PPWR-EPR Compliance platform.

It is intended to accompany the Data Processing Agreement.

The measures are risk based. They may evolve where security is improved, provided that the overall level of protection is not materially reduced.

1. Security Architecture Principles

The Platform is designed around the following security objectives:

confidentiality of customer and regulatory information;

integrity of canonical compliance data and evidence;

availability appropriate to the Service;

separation of organisations and workspaces;

least-privilege access;

strong authentication for privileged access;

traceability of material operations;

controlled credentials;

secure external integrations;

and preservation of regulatory evidence.

GDPR Article 32 requires appropriate measures taking into account the state of the art, implementation costs, Processing context and risk. Eur-Lex

2. Current Technical Measures

3. Authentication

Authentication is separated between browser identity verification and application-session operation.

Firebase identity tokens are verified server side.

In production, Firebase Admin verification is configured to perform revocation-aware token/session verification.

The Platform does not intentionally rely on a long-lived browser Firebase session.

Following authentication, a protected application session is created.

4. Privileged Authentication

Root-level access requires multi-factor authentication.

The inspected implementation specifically checks for an enrolled or used TOTP second factor.

Privileged MFA must not be disabled merely for convenience in production.

Break-glass procedures, if introduced, must be separately documented, restricted and audited.

5. Session Management

Application sessions are short lived.

The current inspected session duration is 45 minutes.

Session cookies are protected against ordinary JavaScript access by the HttpOnly attribute.

Production cookies use Secure transport restrictions.

SameSite controls are applied.

Logout invalidates the relevant session/workspace/CSRF browser state.

6. CSRF Protection

Sensitive browser-originating state changes are protected by CSRF controls.

The inspected Client authentication flow requires consistency between:

the submitted CSRF value;

the request header; and

the protected CSRF cookie.

A timing-safe comparison is used in the relevant Client session exchange.

CSRF tokens have a short lifetime.

7. Workspace and Tenant Isolation

Authentication alone does not provide access to every organisation.

Authorisation decisions incorporate application identity, user membership, roles/capabilities and relevant organisation/workspace scope.

Workspace switching requires the requested organisation to be present within the actor's authorised membership context unless a separate privileged authority applies.

AI tooling likewise performs organisation, Client and country-scope checks.

8. Least Privilege

Access to Personal Data and regulatory data must be limited to the permissions required for the relevant application role.

Privileged capability grants should be assigned only where operationally necessary.

Access must be revoked or modified when a user's organisational relationship or role changes.

9. Secret and Credential Management

Integration credentials, API credentials and webhook secrets are designed to be managed through secret references.

The inspected implementation directly integrates with Google Secret Manager for, among other things:

integration credentials;

AR integration secrets;

communications email credentials;

Resend webhook credentials;

Wise credentials; and

certain connector credentials.

Secret values are retrieved server side.

Application data should retain a secret reference rather than duplicating the cleartext credential where the secret-management path is available.

Secret values must not be written to ordinary application logs.

10. Document Storage Security

Production object storage is designed around Google Cloud Storage.

The implementation separates object references into storage classes including quarantine, validated and evidence states.

Uploaded or generated objects record SHA-256 content hashes.

Document records can also retain object generation/version information.

This supports integrity verification and version-aware deletion.

11. Signed Object Access

When direct object access is required, the storage layer can create Google Cloud Storage V4 signed URLs.

The inspected default expiry is 900 seconds.

Signed URL access should be limited to the shortest period reasonably necessary for the operation.

Possession of a signed URL must not substitute for broader application authorisation controls when a separate application-level permission decision is required.

12. Storage Promotion

Objects intended for document workflows can enter a quarantine storage class and subsequently be validated and promoted into a validated object.

The inspected implementation checks:

document/object scope;

maximum object size;

media-type consistency where expected; and

SHA-256 content integrity.

The inspected default validation maximum is 25 MB unless the calling workflow provides another permitted limit.

This Annex does not represent that malware/antivirus scanning is implemented unless such scanning is separately deployed and documented.

13. Encryption in Transit

Application integrations with Google storage, Secret Manager, Firebase/Google APIs, FCM, Resend and Wise are implemented using HTTPS endpoints.

The Platform shall use modern transport security for Personal Data transmitted over public networks.

14. Encryption at Rest

This Annex does not make a representation that Beyoğlu Professional currently uses customer-managed encryption keys or application-level field encryption for all stored Personal Data.

Managed-cloud encryption-at-rest capabilities may apply through the relevant cloud services.

Any commitment concerning customer-managed keys, key location, HSM use or dedicated encryption domains must be separately agreed and technically verified.

15. Integrity Protection

Cryptographic hashing is used in multiple workflows.

Document content uses SHA-256 integrity hashes.

Webhook and other security flows also use cryptographic verification.

Immutable regulatory data can carry integrity hashes and immutable timestamps.

These controls support detection of unintended or unauthorised modification.

16. Webhook Security

Provider webhooks must not be accepted merely because they reach a public endpoint.

The Wise integration verifies the provider signature against the configured public key/certificate using RSA-SHA256 before accepting the event as verified.

The Resend webhook implementation verifies HMAC-SHA256/Svix-style signatures using timing-safe comparison and rejects timestamps outside the configured tolerance.

Provider-specific webhook authentication methods are used where available.

17. Integration Credentials

External integrations must operate within their configured authentication and scope model.

Production credentials are separated from ordinary UI data.

Revoked or expired credentials should not remain usable.

Provider connections must be disabled or credentials revoked when the integration is terminated.

18. Audit Logging

The Platform maintains structured audit/security-event capabilities.

Events may include:

actor identity;

user profile;

organisation;

application;

source;

correlation identifier;

entity type;

entity identifier;

security/event category;

outcome; and

reason code.

Audit metadata should be minimised to what is necessary for accountability and investigation.

Secret values and unnecessary raw sensitive content must not be placed into audit metadata.

19. AI Security Boundary

AI functionality is subject to a server-controlled security boundary.

User content, documents, attachments, quoted material, retrieved evidence and tool output are treated as untrusted data and cannot override the server security policy.

The AI security boundary prohibits untrusted content from selecting:

provider;

model;

budget policy;

authorisation scope;

tenant;

country scope;

or AR assignment.

20. AI Tool Controls

AI tools operate from an allowlist.

Current security controls require re-authorisation at tool-call time.

Scope can be limited by:

organisation;

Client organisation;

and country.

The AI layer is explicitly prevented from autonomously:

submitting or signing declarations;

sending authoritative communications merely because untrusted content requests it;

releasing or initiating money;

altering posted finance ledgers;

changing AR assignment;

publishing authoritative regulatory rules; or

mutating canonical records outside authorised workflows.

21. Data Minimisation

Canonical compliance processing should use the minimum data necessary for the regulatory purpose.

Commerce integrations should avoid copying unnecessary end-customer identity information into the permanent regulatory ledger where product identity, quantity, destination, event and transaction references are sufficient.

Logs and audit records should likewise avoid storing complete business payloads when an identifier, hash or limited metadata is sufficient.

22. Regulatory Evidence Security

Evidence can be subject to:

immutable status;

retention class;

preserve-until date;

legal hold;

content hash;

version history; and

restricted disclosure.

Deletion controls must respect these governance states.

Archiving a regulatory artifact must not modify the immutable artifact bytes that are required for evidentiary integrity.

23. Secure Erasure

Eligible erasure is implemented as a controlled multi-stage operation.

Before destructive database deletion, the Platform can perform the deletion in a transaction and intentionally roll it back as a preflight.

Only after a successful preflight does final erasure proceed.

Where applicable, erasure includes object storage, Firebase identity and the selected database reference closure.

24. Data Export Before Account Erasure

The account-erasure workflow requires a data export before final account deletion.

The export gathers database records and relevant stored objects into an archive.

A cryptographically random receipt is generated and only its SHA-256 hash is stored in the audit event.

The receipt expires after 30 minutes.

This reduces the risk of accidental irreversible account deletion without first giving the user an opportunity to obtain the account export.

25. Provider Separation

External providers are used for distinct technical functions.

Current source evidence includes capability for:

Google/Firebase identity;

Google Cloud Storage;

Google Secret Manager;

Firebase Cloud Messaging;

Google Vertex AI infrastructure;

Resend email;

Wise financial/payment integration;

and customer-authorised commerce or marketplace integrations.

Presence of provider integration code does not itself establish that every provider is enabled for every production customer.

Production Subprocessor disclosures must therefore be maintained separately and must identify only providers actually used in the relevant production service.

26. International Processing Locations

This Annex deliberately does not specify an EU/EEA hosting region that has not been technically confirmed.

Production region, provider contracting entity and applicable Chapter V transfer mechanism must be maintained in the Subprocessor Schedule and transfer documentation.

27. Incident Response

Processor shall maintain an incident-management process appropriate to the risk and consistent with the DPA.

Security events should be triaged, contained, investigated and remediated.

Personal Data Breaches must be escalated in sufficient time to allow the Controller to satisfy its GDPR obligations.

Incident records must be restricted to personnel with a legitimate need for access.

28. Availability and Recovery

Processor shall maintain availability and recovery controls appropriate to the Services.

However, this Annex does not state a specific RPO, RTO, backup frequency or backup-retention period because these values were not established by the inspected application source.

Any contractual RPO/RTO or backup-duration commitment must be inserted only after the production infrastructure and disaster-recovery configuration has been verified.

29. Vulnerability Management

Processor shall maintain reasonable risk-based processes to identify and remediate security vulnerabilities in the Platform and its dependencies.

Severity, exploitability, exposure and impact on Personal Data should determine remediation priority.

No representation of a particular penetration-testing frequency is made by this Annex unless separately documented.

30. Change Management

Security-relevant application changes should be subject to appropriate review and testing.

Material weakening of the safeguards described in this Annex must not occur without an appropriate security assessment.

Changes to authentication, authorisation, secret handling, erasure, regulatory evidence or tenant isolation should receive heightened review.

31. Personnel and Confidentiality

Personnel receiving privileged access to production Personal Data must:

have a legitimate operational need;

be authorised for that access;

be subject to appropriate confidentiality duties; and

receive access only for the duration of the need.

Access should be removed when the need ceases.

32. Subprocessors

Subprocessors must be subject to contractual data-protection and security obligations consistent with the applicable DPA.

Subprocessor access must be limited to the data required to perform the contracted function.

The current Subprocessor Schedule must be maintained separately from this Annex because service providers and processing locations can change independently of the application code.

33. Review and Testing

These measures must be periodically reviewed for effectiveness and adjusted in response to:

material architecture changes;

security incidents;

new threats;

changes in Processing risk;

changes in applicable law; and

material changes to Subprocessors.

34. No Unverified Certification Claims

Unless separately documented in writing, this Annex does not represent that Beyoğlu Professional itself currently holds:

ISO/IEC 27001 certification;

SOC 2 certification;

PCI DSS certification;

a particular governmental security accreditation;

or another third-party security certification.

Likewise, this Annex does not promise a particular data residency region, dedicated HSM, customer-managed encryption keys, 24/7 SOC operation, specified penetration-test frequency, RPO or RTO unless separately agreed and verified.

This provision prevents security documentation from creating commitments that do not correspond to the deployed system.

35. Security Contact

Security and data-protection matters:

https://beyogluprofessional.com/contact
https://beyogluprofessional.com/contact