BEYOĞLU PROFESSIONAL TECHNICAL AND ORGANISATIONAL MEASURES SCHEDULE

BEYOĞLU PROFESSIONAL TECHNICAL AND ORGANISATIONAL MEASURES SCHEDULE Technical and Organisational Measures — TOMs Version: 1.0
Effective Date: 1 October 2026
Last Updated: 1 October 2026 This Technical and Organisational Measures Schedule (“TOMs Schedule”) forms part of the Data Processing Agreement (“DPA”) applicable to the Beyoğlu Professional PPWR-EPR Platform, Client Portal and related Services. Capitalised terms not defined in this Schedule have the meanings given in the DPA. For purposes of this Schedule, “Beyoğlu” means the Beyoğlu Professional contracting entity identified in the applicable DPA, Order Form or Service Agreement.

1. Purpose and Scope Beyoğlu maintains technical and organisational measures designed to provide a level of security appropriate to the risks associated with the Processing of Personal Data. These measures are designed with regard to: (a) the nature, scope, context and purposes of Processing; (b) the categories and volume of Personal Data processed; (c) the state of the art; (d) implementation costs; (e) the likelihood and severity of risks to the rights and freedoms of Data Subjects; and (f) Beyoğlu’s obligations under applicable Data Protection Law. The measures described in this Schedule apply to systems and services used by Beyoğlu to process Customer Personal Data as Processor. Some infrastructure-level controls are provided by authorised cloud or technology Subprocessors. Such inherited controls form part of Beyoğlu’s overall security architecture where applicable to the relevant Service. This Schedule describes the security baseline. It does not represent that every optional control is enabled for every Customer, user, integration or feature.

2. Security Principles Beyoğlu’s security architecture is based on the following principles:

• least-privilege access;
• need-to-know authorisation;
• separation of Customer workspaces;
• layered authentication and authorisation;
• secure credential handling;
• data minimisation;
• traceability and auditability;
• integrity-preserving records;
• secure-by-default application behaviour;
• controlled integrations;
• fail-closed processing for material security or compliance conditions;
• controlled data retention and deletion;
• incident detection and response; and
• periodic reassessment of security measures. Beyoğlu may replace individual controls with controls that provide materially equivalent or stronger protection, provided that the overall security of the Processing is not materially reduced.

3. Information Security Governance Beyoğlu maintains responsibility for security governance across the Platform. Security responsibilities are allocated according to role and system function. Administrative, operational and technical access is limited according to authorised duties. Security-relevant system areas include, as applicable:

• identity and access management;
• application access control;
• Customer workspace isolation;
• integration security;
• credential management;
• document and evidence storage;
• audit logging;
• provider management;
• communications;
• regulatory data processing;
• financial operations;
• data-export and deletion workflows;
• AI-assisted processing; and
• incident management. Security controls are reviewed when material architectural, regulatory or processing changes occur.

4. Identity Management Portal users are associated with individual user identities rather than generic shared user accounts wherever technically practicable. Identity information may include a unique identity identifier, verified email address, account status, organisation memberships, assigned roles and authorised capabilities. Beyoğlu uses an identity-provider architecture to authenticate Portal users. Access to authenticated functionality requires successful identity verification and a valid authenticated session. Where email verification is required by the applicable Portal flow, access is not activated until the email address has been verified. Beyoğlu may disable an identity, revoke sessions, deactivate memberships or otherwise terminate access where required for security or account administration.

5. Authentication Controls Authentication measures include, as applicable: (a) verified identity-provider credentials; (b) recent-authentication requirements for sensitive authentication operations; (c) server-side session validation; (d) secure session cookies; (e) session expiry; (f) session revocation; (g) additional authentication requirements for privileged identities; and (h) multi-factor authentication for designated privileged or high-risk access. Privileged/root administrative access is subject to additional MFA requirements. Beyoğlu may expand mandatory MFA requirements according to risk, role, Customer configuration or security policy. The absence of mandatory MFA for a particular ordinary user role does not prevent the Customer from applying appropriate internal authentication and endpoint controls to its users.

6. Session Security Authenticated browser sessions are maintained using security-controlled cookies. Production session cookies are configured using security attributes including, as applicable:

• HttpOnly;
• Secure;
• SameSite;
• constrained cookie paths; and
• defined expiry or maximum lifetime. Session cookies are not intentionally exposed to browser-side application code where HttpOnly protection applies. Logout operations clear relevant authentication and workspace cookies. Invalid or expired sessions are rejected. Cache-control restrictions are applied to sensitive authentication responses where appropriate.

7. Cross-Site Request Forgery Protection Security-sensitive browser operations use anti-CSRF protections. The Portal architecture includes cryptographically generated CSRF values and validation between the expected request token and corresponding protected request state. CSRF cookies are issued with restrictive cookie attributes. Requests failing required CSRF validation are rejected rather than processed.

8. Authorisation and Least Privilege Authentication alone does not grant unrestricted Platform access. Beyoğlu applies role-, capability- and resource-based authorisation controls. Authorisation may depend upon:

• user role;
• organisation membership;
• active workspace;
• country scope;
• Customer scope;
• finance permission;
• application;
• resource ownership;
• action type; and
• specific capability. Customer roles may include, for example:
• Client Owner;
• Client Compliance;
• Client Operations;
• Client Finance; and
• Client Viewer. Capabilities are separated between read and write operations and between functional domains. Access attempts outside the authorised resource scope are rejected.

9. Tenant and Workspace Segregation Customer data is logically segregated using organisation, Customer, Country Compliance Account, workspace and other applicable ownership identifiers. A user may access a workspace only where the user has a corresponding membership or another explicit authorised relationship. Cross-workspace access is not granted merely because a user is authenticated. Queries and service operations are designed to apply applicable tenant or resource scope before sensitive records are returned or modified. Authorised Representative and HQ access are governed through their own role and scope models rather than through unrestricted Customer access.

10. Privileged Access Privileged administrative functionality is separated from ordinary Customer functionality. Privileged access is limited to users with corresponding roles and capabilities. Material administrative activities may be recorded through audit events. Beyoğlu uses additional controls for privileged identities, including MFA requirements for designated root-level access. Administrative access must be used only for legitimate operational, security, support or compliance purposes.

11. Credential and Secret Management Secrets are not intended to be persisted in ordinary application records where a secure secret-reference mechanism is available. Sensitive integration material may include:

• API secrets;
• OAuth client secrets;
• OAuth access tokens;
• OAuth refresh tokens;
• webhook secrets;
• private keys;
• certificates; and
• provider credentials. Such material is stored or referenced through designated secret-management mechanisms. Application records should normally retain a secret reference rather than the underlying secret. Existing secret values are not exposed through ordinary administration interfaces after secure creation or storage. Where a newly generated credential must be presented to an authorised administrator, the secret may be displayed once for secure capture.

12. API Key Security Platform-issued API credentials use cryptographically generated secret material. API credentials are stored in a form designed to avoid retaining the usable API secret in plaintext in the application database. API-key verification may use cryptographic hashing and constant-time comparison techniques to reduce exposure to credential-recovery and timing attacks. API credentials may be:

• scoped;
• rotated;
• revoked;
• disabled;
• associated with a specific connection;
• associated with sandbox or production environments; and
• audited. Where applicable, production credential issuance may be subject to additional activation controls.

13. Integration Credential Lifecycle Integration credentials are associated with defined connection instances and lifecycle states. Credential-management functions may include:

• creation;
• activation;
• rotation;
• replacement;
• revocation;
• expiry;
• testing; and
• removal from active use. Replacing a credential does not require destruction of audit evidence showing that the previous credential existed or was revoked. Secret values should not be included in ordinary audit metadata.

14. Encryption in Transit Beyoğlu uses encrypted transport for production web and API communications. HTTPS/TLS is used for externally exposed production Portal communication where supported by the relevant infrastructure. Cloud-provider service-to-service encryption and authenticated transport protections are relied upon where processing occurs within managed cloud infrastructure. Where third-party integrations support secure transport, Beyoğlu uses the provider’s secure HTTPS or equivalent authenticated transport endpoints. Unencrypted transport must not be introduced for Customer Personal Data without a documented security assessment and appropriate compensating control.

15. Encryption at Rest Production Customer content hosted using Google Cloud services benefits from Google Cloud’s default encryption-at-rest mechanisms. Relevant managed cloud storage and infrastructure may apply provider-managed cryptographic controls to stored Customer Data and backups. Credential material held in designated Secret Manager services benefits from the security controls applicable to that service. Where Beyoğlu introduces another infrastructure provider that processes Customer Personal Data, appropriate at-rest protection will form part of the supplier security assessment. This Section does not represent that Customer-managed encryption keys are enabled unless specifically agreed or documented.

16. Cryptographic Integrity Controls Cryptographic hashes are used for selected security and integrity functions. Examples include:

• API-key hashing;
• document content hashes;
• evidence hashes;
• stored-object hashes;
• regulatory-source hashes;
• source fingerprints;
• idempotency or provenance identifiers; and
• integration signature verification. SHA-256 is used in several Platform integrity controls. A cryptographic content hash may be retained with a document or evidence version to support subsequent integrity verification.

17. Document and Evidence Integrity Documents and compliance evidence may be stored with:

• version identifiers;
• previous-version relationships;
• original filenames;
• media types;
• byte lengths;
• content hashes;
• storage references;
• storage-object versions;
• uploader identities;
• timestamps;
• source-provider information;
• retention classifications;
• immutable timestamps; and
• immutable reasons. Where a document is designated as immutable evidence, later operational changes should not silently alter the historical stored version. Subsequent changes are represented using a new version or other governed record where required.

18. File Handling and Validation File-processing workflows may include a distinction between quarantine/unvalidated and validated storage states. Depending on the applicable workflow, controls may include:

• maximum file-size limits;
• expected media-type checks;
• filename sanitisation;
• storage-scope validation;
• content hashing;
• object-reference validation; and
• controlled promotion into validated storage. A file that fails a mandatory validation condition may be rejected instead of being accepted as canonical evidence.

19. Application Input Validation Application services perform server-side validation of sensitive inputs. Validation may include:

• required-field checks;
• permitted enumerations;
• reference validation;
• identifier format validation;
• country-code validation;
• quantity and numeric range checks;
• status-transition rules;
• file limits;
• permission checks; and
• idempotency controls. Front-end validation is not treated as a substitute for server-side validation.

20. Webhook Security Where supported by the relevant provider, inbound webhooks are verified before the data is promoted into trusted processing. Verification mechanisms may include:

• HMAC signatures;
• signed JWT verification;
• webhook-specific signature headers;
• webhook secrets;
• provider public keys;
• event identifiers;
• timestamp validation;
• source binding; and
• replay controls. Webhook processing fails closed where the required security boundary cannot be validated. Beyoğlu does not manufacture or assume a webhook-signature mechanism where a provider does not support one. Unsupported or inadequately secured integrations may remain unavailable or require a controlled alternative mechanism.

21. OAuth and External Authorisation OAuth-based integrations use controlled authorisation flows. Measures may include:

• approved redirect URIs;
• requested-scope restriction;
• cryptographically generated nonce or state values;
• state expiry;
• state integrity or confidentiality protections;
• provider-specific callback validation; and
• secure storage of resulting credentials. Scopes should be limited to those reasonably necessary for the relevant integration.

22. Data Minimisation Beyoğlu applies data-minimisation principles to the design of compliance and commerce integrations. Where detailed consumer information is not necessary for PPWR/EPR processing, the Platform seeks to rely on more limited information such as:

• order or fulfilment reference;
• SKU;
• quantity;
• country;
• timestamp;
• commercial classification; and
• regulatory-relevant packaging information. Third-party provider payloads may contain additional Personal Data. Such additional data must not be intentionally used beyond the applicable legitimate Processing purpose.

23. Data Protection by Design and Default New or materially changed processing functions are expected to consider privacy and security requirements during design. Relevant design considerations include:

• minimum necessary data;
• default access restrictions;
• segregation of roles;
• traceability;
• lifecycle controls;
• retention requirements;
• exportability;
• deletion requirements;
• international transfers;
• Subprocessors;
• credentials; and
• potential impact upon Data Subjects. High-risk Processing will be subject to additional privacy or security assessment where required by applicable law.

24. Audit Logging The Platform maintains audit records for designated security, administrative, compliance and data-management events. Audit information may contain:

• actor identity;
• actor organisation;
• action;
• affected entity type;
• affected entity identifier;
• correlation identifier;
• event time;
• result or status; and
• appropriately limited metadata. Audit records are intended to support accountability, troubleshooting, security investigations and regulatory evidence. Audit metadata should be designed not to unnecessarily expose raw secret material.

25. Security Logging and Monitoring Authentication and other security-relevant events may be separately recorded from ordinary business audit events. Recorded security events may include, depending on system component:

• session creation;
• authentication failure;
• invalid sessions;
• logout;
• membership changes;
• credential lifecycle events;
• webhook verification failures;
• integration failures;
• queue failures;
• system health events; and
• privileged configuration changes. Operational workspaces provide visibility into selected failures, retries, webhooks, synchronisation operations, connection health and security conditions.

26. Integration Execution Traceability Integration operations maintain operational provenance where appropriate. Such provenance may include:

• provider;
• connection;
• external reference;
• event identifier;
• source fingerprint;
• sync run;
• processing result;
• retry state;
• queue state;
• timestamp; and
• error information. The Platform may retain failed or rejected integration events where necessary for diagnosis, security, accountability or controlled recovery.

27. Controlled Retry and Replay Automated retry and webhook replay functions are governed rather than treated as unrestricted re-execution mechanisms. Where applicable, the system distinguishes between:

• queued;
• leased;
• completed;
• failed;
• retryable; and
• dead-letter or held-for-review work. Recovery actions are subject to corresponding permissions. Where external state must first be reconciled, blind retry may be disallowed.

28. Data Integrity and Historical Records Compliance-relevant historical facts are not ordinarily silently rewritten. The Platform may use:

• versioning;
• append-only ledgers;
• reversal events;
• correction records;
• replacement relationships;
• immutable evidence;
• source provenance; and
• audit events to preserve historical traceability. This approach is particularly relevant to sales, shipments, placed-on-market events, regulatory quantities, declarations and evidence.

29. Database and Object Storage Customer records are primarily stored through managed database and object-storage services configured for the Platform. Access from application services is restricted through infrastructure identities, credentials and application-level authorisation. Direct storage references do not themselves grant user access. Application permission checks continue to apply to Customer-facing retrieval. Local filesystem storage modes used for development or controlled local environments are not intended to substitute for required production storage configuration.

30. Availability and Resilience Beyoğlu uses managed cloud infrastructure and application-level operational controls designed to support availability and resilience. Relevant measures may include:

• managed compute services;
• managed database services;
• managed object storage;
• provider redundancy;
• queued processing;
• retries;
• failure-state preservation;
• health monitoring; and
• recovery tooling. Specific contractual RTOs, RPOs, availability percentages or disaster-recovery guarantees apply only where expressly stated in an SLA, Order Form or Service Agreement. Beyoğlu does not represent through this Schedule alone that a specific Customer-specific RPO or RTO has been agreed.

31. Backup and Recovery Where production database, object-storage or infrastructure backup services are enabled, backups are protected using applicable provider security controls. Backup and restoration configuration is governed through production infrastructure and operational procedures. Beyoğlu maintains recovery capability appropriate to the relevant service and risk. Where a Customer requires contractual backup frequency, retention period, RPO or RTO commitments, those values must be expressly stated in the applicable commercial or service documentation.

32. Business Continuity Beyoğlu maintains operational arrangements intended to permit continuation or orderly restoration of material Services following a significant technical disruption. Business-continuity measures are proportionate to service criticality. Dependencies upon cloud infrastructure and material Subprocessors are considered as part of service-continuity planning. Beyoğlu may use alternative operational procedures where automated systems are temporarily unavailable and such alternatives remain legally and operationally appropriate.

33. Security Incident Management Beyoğlu maintains procedures to identify, investigate, contain, remediate and document material security incidents. Security incidents are assessed to determine whether they constitute a Personal Data Breach. Incident handling may include:

1. detection or notification;

2. initial triage;

3. containment;

4. preservation of relevant evidence;

5. investigation;

6. scope and impact analysis;

7. remediation;

8. recovery;

9. required Customer or regulatory notification; and

10. post-incident review. Where Beyoğlu acts as Processor and becomes aware of a Personal Data Breach affecting Customer Personal Data, notification to the Customer will be made in accordance with the DPA and applicable Data Protection Law.

34. Incident Evidence Beyoğlu may preserve audit records, logs, correlation identifiers, hashes, provider events, relevant configuration history and other information reasonably necessary to investigate an incident. Incident evidence is subject to access restriction and confidentiality requirements. Incident investigations must not result in unrestricted access to unrelated Customer Data.

35. Vulnerability and Security Defect Management Security defects identified in application code, dependencies, configuration or infrastructure are assessed according to their risk. Beyoğlu may take measures including:

• patching;
• dependency updates;
• configuration changes;
• credential rotation;
• temporary feature restriction;
• access revocation;
• additional monitoring; or
• emergency deployment. A critical security remediation may be deployed outside an ordinary feature-release schedule.

36. Secure Development and Change Management Source-code changes are maintained through controlled development processes. Material changes should be subject to appropriate review, testing or automated validation before production deployment. Testing may include, where applicable:

• type checking;
• contract testing;
• unit tests;
• integration tests;
• negative authorisation tests;
• migration validation;
• security-boundary tests; and
• regression tests. Changes affecting sensitive data flows should preserve tenant and authorisation boundaries.

37. Separation of Environments Production and non-production environments are logically distinguished. Production credentials are not intended to be reused indiscriminately in local or test environments. Certain development-only functionality is prevented from being used as a substitute for mandatory production infrastructure. Sandbox integration credentials and production credentials may be separately identified and controlled. Test data should not contain production Personal Data unless there is a documented need and corresponding protection.

38. Personnel Security and Confidentiality Persons with authorised access to Customer Personal Data must be subject to appropriate confidentiality obligations. Access is limited according to job responsibilities and legitimate operational need. Access must be removed or adjusted when responsibilities change or employment or engagement terminates. Privileged access must not be used for personal, unauthorised or unrelated purposes. Security and data-protection obligations apply to authorised contractors as appropriate to their role.

39. Subprocessor Security Before permitting a direct Subprocessor to process Customer Personal Data, Beyoğlu assesses whether that Subprocessor provides sufficient security and data-protection guarantees appropriate to the processing. Subprocessors are contractually required to apply appropriate protections as required under the DPA and applicable Data Protection Law. Beyoğlu’s then-current Subprocessor Schedule identifies the relevant direct Subprocessors and applicable processing functions.

40. Physical Security Core production infrastructure is hosted using professional managed cloud providers. Physical security of the relevant data-centre infrastructure is therefore principally provided by the applicable infrastructure Subprocessor. Beyoğlu does not operate Customer production workloads from an ordinary office workstation or local development computer as a substitute for the designated production infrastructure. Beyoğlu evaluates provider physical-security assurances as part of provider risk and due diligence.

41. Data Subject Rights and Customer Assistance The Platform includes mechanisms designed to support data access, export and deletion obligations. Where Beyoğlu acts as Controller, Data Subject rights are handled under the applicable Privacy Policy and Data Protection Law. Where Beyoğlu acts as Processor, Beyoğlu provides reasonable assistance to the Customer as required by the DPA. Account data export functionality is designed to be independent of account-deletion eligibility. Where the export mechanism identifies associated database records and binary objects, the export process is designed not to knowingly return an incomplete archive as if it were complete.

42. Data Export Security Data-export functionality requires authenticated and authorised access. Exports may contain sensitive Customer information and must therefore be made available only to an appropriately authorised account. The system may package structured database records and associated stored objects into a single archive. Exports are scoped to the authorised account or Customer context. Another Customer’s data, Provider credentials, infrastructure secrets and data outside the authorised scope must not be intentionally included. Customers are responsible for securely storing downloaded archives after delivery.

43. Data Retention Customer Personal Data is retained according to:

• Processing purpose;
• Customer instructions where Beyoğlu acts as Processor;
• statutory requirements;
• financial and accounting requirements;
• EPR/PPWR and regulatory recordkeeping;
• active contractual relationships;
• legal claims;
• evidence requirements;
• security obligations; and
• defined retention classifications. The presence of an account-deletion request does not require Beyoğlu to destroy information that must lawfully be retained for another purpose. Retention periods or criteria are addressed in the DPA, Privacy Policy, relevant regulatory record or applicable retention schedule.

44. Secure Deletion Personal Data is deleted or anonymised when the applicable retention obligation expires and continued retention is no longer required, subject to technical backup lifecycle and applicable law. Deletion operations are authorised and scoped to the appropriate Customer, account or resource. Deletion of an individual user does not automatically delete organisation-owned compliance records that must remain available to the Customer or for lawful retention. Where Beyoğlu acts as Processor, return and deletion following termination are performed in accordance with the DPA.

45. Data Portability and Exit Beyoğlu maintains mechanisms intended to permit Customer Data to be exported in commonly usable structured or file-based formats where reasonably applicable. Export mechanisms may include structured JSON, CSV, spreadsheet files, document files and archive packages depending on the relevant data domain. Data portability measures are intended to support contractual exit, Customer transparency and applicable legal portability or switching obligations. Provider proprietary source code, security secrets, information belonging to another Customer and data that cannot lawfully be disclosed are excluded.

46. AI-Assisted Processing Where AI-assisted functionality is enabled, access to Customer content remains subject to applicable authorisation controls. AI processing is limited to content and context authorised for the relevant operation. Provider credentials are managed using controlled provider configuration and secret references. Beyoğlu will assess material changes to AI providers or AI processing against the applicable DPA, Subprocessor Schedule, international-transfer requirements and privacy obligations before such changes are introduced into Customer Personal Data processing. Where a human review is required for legal, regulatory or material business consequences, AI output will not be treated solely as a substitute for that required review.

47. Sensitive and Special Category Data The Platform is not designed to require unnecessary Special Category Personal Data. Customers must not intentionally upload health data, biometric data, political opinions, religious beliefs, sexual-life data or other Article 9 GDPR data unless: (a) the Processing is necessary; (b) a valid legal basis and Article 9 condition exist; (c) Beyoğlu has been informed where required; and (d) suitable safeguards have been agreed. Where Special Category Data becomes necessary for a particular contracted workflow, additional safeguards may be agreed.

48. Production Logging and Data Minimisation Logs are designed primarily for security, operations, debugging, audit and accountability. Where practicable, logs should contain identifiers, status information, event information and limited metadata instead of unnecessary full content. Credentials, raw passwords and reusable authentication secrets must not intentionally be written to ordinary application logs. Security-sensitive diagnostic output is subject to access restrictions.

49. Testing of Security Measures Beyoğlu periodically assesses the effectiveness of relevant security measures through technical and operational testing proportionate to the risk. Testing may include:

• automated tests;
• authorisation-negative tests;
• authentication tests;
• integration-signature tests;
• data-isolation tests;
• type and build checks;
• security-control regression tests;
• provider health checks;
• recovery tests; and
• manual review. The exact testing frequency may vary according to the relevant control and risk. Material deficiencies are tracked for remediation according to risk and priority.

50. Customer Security Responsibilities Security is a shared responsibility. The Customer is responsible for:

• maintaining authorised user lists;
• promptly removing former personnel;
• assigning appropriate roles;
• protecting user endpoints;
• selecting strong authentication credentials;
• enabling available enhanced authentication appropriate to its risk;
• protecting API keys downloaded by the Customer;
• securing downloaded data archives;
• managing Customer-controlled third-party credentials;
• selecting appropriate integration scopes;
• reviewing access permissions;
• promptly reporting suspected compromise; and
• ensuring that Personal Data uploaded to the Platform is lawfully collected and disclosed. A failure by the Customer to perform its own security responsibilities does not remove Beyoğlu’s independent obligations under applicable Data Protection Law.

51. Security Information and Audit Assistance Upon reasonable request, Beyoğlu will provide information reasonably necessary for the Customer to assess compliance with the security obligations in the DPA. Such information may include:

• this TOMs Schedule;
• relevant architecture information;
• applicable cloud security documentation;
• Subprocessor information;
• security-control summaries;
• relevant testing information;
• incident information where applicable; or
• independent assurance documentation where available. Beyoğlu may redact information where disclosure would create a material security risk, expose another Customer’s information, disclose credentials or reveal protected confidential information. Audit rights are governed by the DPA.

52. International Transfers and Security Where Customer Personal Data is subject to an international transfer requiring safeguards under GDPR Chapter V, Beyoğlu will apply the transfer mechanism specified in the DPA or Subprocessor Schedule. Technical and organisational safeguards relevant to the transfer may include:

• encryption;
• access restriction;
• data minimisation;
• provider security controls;
• transfer-risk assessment;
• contractual commitments;
• logging; and
• credential segregation. This Schedule may also be used as supporting security information for the technical-measures annex of applicable Standard Contractual Clauses, subject to any additional information required by those clauses.

53. Certifications and Assurance No ISO, SOC, PCI, BSI, NIS2 or other certification is represented as a Beyoğlu certification solely by inclusion of this Schedule. Where Beyoğlu relies upon a certified Subprocessor or infrastructure provider, that certification belongs to the applicable provider unless expressly stated otherwise. Any future Beyoğlu certification will be identified separately and only after formally obtained.

54. No Absolute Security Warranty Beyoğlu maintains measures intended to provide security appropriate to the risk. No information system can be guaranteed to be entirely free from security incidents, vulnerabilities or unauthorised attacks. This limitation does not reduce Beyoğlu’s obligation to implement appropriate measures, remedy known material deficiencies, comply with the DPA or meet mandatory Data Protection Law.

55. Material Changes Beyoğlu may update these TOMs to reflect:

• changes in technology;
• improvements to security;
• changes in infrastructure;
• regulatory changes;
• changes in Subprocessors;
• changes in threat conditions; or
• changes to the Services. Beyoğlu will not materially reduce the overall protection of Customer Personal Data during the applicable Processing term without an appropriate legal basis or Customer agreement where required. Material changes relevant to the Customer’s rights under the DPA will be communicated in accordance with the DPA.

56. Order of Precedence If this Schedule conflicts with a specific security commitment contained in a signed Order Form or Service Agreement, the more specific contractual security commitment governs for the Services covered by that document. If this Schedule conflicts with mandatory Data Protection Law, mandatory law prevails. If this Schedule conflicts with the DPA on a matter specifically governed by the DPA, the DPA prevails.

ANNEX A — CURRENT SECURITY CONTROL MATRIX

ANNEX B — DATA SECURITY ARCHITECTURE SUMMARY

Primary production environment: Google Cloud Platform. Application processing: managed cloud compute services. Primary structured data: managed relational database infrastructure. Documents and evidence: managed object-storage infrastructure. Credentials and secrets: designated secret-management services and secret references. Identity: Firebase / Google identity infrastructure where applicable. Operational email: authorised communication provider as identified in the Subprocessor Schedule. AI-assisted processing: authorised AI provider only where the applicable feature is enabled. Data residency: production services are configured principally within the EEA where stated in the Subprocessor Schedule; individual provider support, metadata and downstream processing locations remain governed by the applicable Subprocessor terms.

ANNEX C — CUSTOMER-SPECIFIC ENHANCED SECURITY OPTIONS Where agreed in an Order Form, the parties may specify additional controls, including:

• mandatory MFA for all Customer users;
• customer-managed encryption keys;
• dedicated cloud resources;
• IP allowlisting;
• SSO/SAML;
• SCIM;
• shortened session lifetimes;
• customer-specific audit export;
• enhanced logging;
• additional penetration testing;
• defined RPO;
• defined RTO;
• defined backup retention;
• private network connectivity;
• dedicated data residency;
• additional incident-notification contacts; or
• other Customer-specific controls. No Annex C measure applies unless expressly activated or agreed.