BEYOĞLU PROFESSIONALPPWR-EPR COMPLIANCE SERVICES
Home·Data & Security Policy
Trust, Data & Security

Data & Security Policy

This page explains the security principles applied to Beyoğlu Professional PPWR-EPR services, how we separate the public website from operational compliance systems, and how security responsibilities are shared between Beyoğlu, customers and infrastructure providers.

Last reviewed 9 September 2026Version 3.0
Trust, Data & Security

Our security position

Regulatory evidence is operational business data. Producer identities, national registrations, packaging ledgers, declarations, payment records and statutory mandates can affect a customer's ability to operate in a market. We therefore treat confidentiality, integrity, availability, traceability and recoverability as operational requirements rather than marketing language.

1. Corporate responsibility

Current operating disclosure

ItemCurrent position
Service brandBeyoğlu Professional — PPWR-EPR Compliance Services
Current business entityTHEMİR MEDYA İNŞAAT İTHALAT İHRACAT SANAYİ TİCARET ANONİM ŞİRKETİ
Current baseİstanbul, Türkiye
Current public websiteStatic-first public website delivered through cloud object storage and CDN infrastructure
Production compliance architectureOperated separately from the public information layer. Authenticated application, API, data, payment and evidence services use distinct runtime and storage controls where required. The public website must not be read as evidence that every operational-system control applies to the static public layer, or vice versa.

2. Security principles

Controls are selected according to risk, not according to marketing language.

Controls are selected according to risk, not according to marketing language.

Confidentiality — Least-privilege access.

Users and personnel should have only the permissions necessary for their role and the customer or regulatory operation concerned.

Integrity — Versioned compliance data.

Material packaging and regulatory data should not be silently overwritten where doing so would destroy the historical basis of an earlier declaration.

Availability — Backup and recovery.

Production records should be backed up and recoverable according to their operational and regulatory importance.

Traceability — Event and evidence linkage.

Material compliance actions should be linkable to source data, account, time, country and resulting evidence.

Minimisation — Only data needed for the task.

Integrations should avoid collecting consumer identity data where destination, parcel and SKU information is sufficient.

Review — Controls evolve with risk.

Security measures must be reassessed as countries, integrations, customer volumes and payment operations expand.

3. GDPR Article 32

Security measures must be appropriate to the actual risk.

Where the GDPR applies, Article 32 requires controllers and processors to implement security measures appropriate to the risk, taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing, and the likelihood and severity of risks to individuals.

Relevant controls can include, where appropriate, encryption and pseudonymisation, measures supporting confidentiality, integrity, availability and resilience, recovery capability, and regular testing and evaluation of security measures.

Beyoğlu does not use an ISO certification, encryption algorithm or security standard as a marketing claim unless the relevant implementation or certification can actually be evidenced.

4. Identity and access

Access to a compliance file should follow the customer's organisation.

Access to a compliance file should follow the customer's organisation and the user's authorised role.

Production account architecture is intended to use authenticated accounts and role-based permissions appropriate to the service.

Customer administrators are responsible for ensuring that accounts are not shared with unauthorised people and that access is removed when personnel leave or change roles. Beyoğlu may revoke or suspend credentials where compromise, abuse or unauthorised access is suspected.

5. API security

A compliance API should not become an unnecessary copy of the customer's customer database.

A compliance API should not become an unnecessary copy of the customer's customer database.

Integrations should transmit the minimum structured information necessary for the compliance task. Typical compliance data can include merchant identifier, order or shipment reference, destination Member State, SKU, quantity, parcel count, fulfilment route, shipment event and return or cancellation status.

Consumer names, personal telephone numbers, personal email addresses and full delivery addresses should not be transmitted where the compliance purpose can be achieved without them.

API credentials should be treated as secrets, stored outside public client-side code and rotated or revoked if compromise is suspected.

6. Regulatory evidence integrity

Historical declarations need historical source data.

Historical declarations need historical source data.

Where a packaging profile changes, production architecture should preserve the version used for earlier reporting rather than replacing the historical record with the current SKU configuration.

Registration records, filing confirmations, reports, invoices and payment evidence should remain attributable to the corresponding country and period. This supports both customer auditability and the ability to answer a later authority or marketplace query.

7. Regulatory funds

Safeguarding architecture is a legal-control question, not merely an accounting preference.

Safeguarding architecture is a legal-control question, not merely an accounting preference.

Beyoğlu's intended regulatory-prefunding model does not rely on treating customer regulatory balances as ordinary operating revenue.

Where customer money must be held before transfer to an authority, Producer Responsibility Organisation (PRO) or system, the intended structure is to use a licensed payment service provider, safeguarded client-money arrangement or another legally compliant third-party payment model.

No specific payment provider or safeguarding institution is identified on this page until the relevant agreement is actually in force. Once that infrastructure becomes operational, the provider, payment flow and customer-fund treatment should be disclosed separately.

8. Public website infrastructure

We distinguish the public information layer from the operational compliance platform.

We separate the public information website from the operational compliance platform.

The current Beyoğlu Professional public website is published using a static-first architecture. Public pages are pre-rendered and delivered through cloud object storage and CDN infrastructure. Ordinary public pages do not require access to customer compliance records merely in order to render website content.

Operational services that require authentication, APIs, databases, secrets, payment orchestration or other server-side runtime are handled separately from the static public website and are subject to controls appropriate to those functions.

We do not turn the security features of one provider or one delivery layer into unsupported claims about the entire Beyoğlu platform.

9. Providers and subprocessors

A provider is assessed according to the data and task entrusted to it.

A provider is assessed according to the data and task entrusted to it.

Production providers can include hosting, authentication, communications, security, payment and other technical services. Where a provider processes personal data on behalf of Beyoğlu and GDPR Article 28 applies, an appropriate processing arrangement is required.

Where a provider acts independently — for example a bank, authority, PRO or marketplace acting for its own purposes — it may operate as an independent controller rather than as a Beyoğlu subprocessor.

10. International data transfers

We do not describe processing in Türkiye as an intra-EU transfer.

We do not describe processing in Türkiye as an intra-EU transfer.

The current operating entity is in Türkiye. Türkiye is not currently covered by an EU GDPR adequacy decision. Where GDPR Chapter V applies to a transfer, an appropriate transfer mechanism may therefore be required, such as Standard Contractual Clauses together with supplementary measures where appropriate to the processing relationship.

Further information on personal-data processing and transfers is set out in the Privacy Policy. If that page is not yet available in the selected language, this cross-reference will become active when the corresponding policy is published.

11. Security incidents

An incident is documented even where it does not ultimately require regulatory notification.

An incident is documented even where it does not ultimately require regulatory notification.

Incident response can include detection, containment, evidence preservation, credential revocation, assessment of affected systems and data, recovery and corrective measures.

Where the GDPR applies, a reportable personal-data breach must be notified to the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after the controller becomes aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Where a breach is likely to create a high risk, affected individuals must also be informed without undue delay unless a GDPR exception applies.

12. Business continuity

Compliance continuity matters because deadlines continue even when technology fails.

Compliance continuity matters because regulatory deadlines continue even when technology fails.

Production architecture should include backup, recovery and evidence-export mechanisms appropriate to the regulatory importance of the data. Where an external authority portal is unavailable, Beyoğlu may preserve attempted-action evidence, relevant timestamps and later submission evidence where operationally appropriate.

13. Customer responsibilities

A secure platform cannot compensate for compromised customer credentials.

A secure platform cannot compensate for compromised customer credentials. Customers are expected to:

  • protect account credentials and API secrets
  • use separate authorised user accounts where provided
  • remove access from users who no longer require it
  • protect their own commerce and ERP systems
  • transmit only the data necessary for the compliance purpose
  • notify Beyoğlu promptly of suspected compromise; and
  • maintain accurate product and packaging source data

14. Certifications and claims

We will not claim a certification before we have it.

We will not claim a certification before we have it.

This page does not state that Beyoğlu Professional is ISO 27001 certified, SOC 2 certified, PCI DSS certified or the holder of another security certification unless and until such certification is formally obtained and its scope can be identified.

Likewise, we do not state that all information is hosted exclusively inside the European Union where the current infrastructure does not support that statement.

Security concern?

Identify the affected page, account, API or transaction and provide enough technical detail for investigation without publishing credentials, tokens or other secrets in a public channel. Use the Beyoğlu Professional contact page to report a security concern.

Report a security concern