Data & Security Policy
This page describes the security principles used for the Beyoğlu Professional PPWR-EPR service, the controls we expect from the production platform, the current limitations of the public website environment and the way security responsibilities are divided between Beyoğlu, customers and infrastructure providers.
Regulatory evidence is operational business data. We do not describe it as harmless website content.
Producer identities, national registration information, packaging ledgers, declarations, payment records and statutory mandates can affect a customer's ability to sell in a market. Security controls are therefore designed around confidentiality, integrity, availability, traceability and recoverability.
1 · Corporate responsibility
Current operating disclosure
| Service brand | Beyoğlu Professional — PPWR-EPR Compliance Services |
|---|---|
| Current business entity | THEMİR MEDYA İNŞAAT İTHALAT İHRACAT SANAYİ TİCARET ANONİM ŞİRKETİ |
| Current base | İstanbul, Türkiye |
| Current public website | Tilda-based website infrastructure |
| Production compliance architecture | Developed separately from the public information layer as the operational platform is rolled out. We do not imply that every future control is already provided by the present Tilda website. |
2 · Security principles
Controls are selected according to risk, not according to marketing language.
Least-privilege access
Users and personnel should have only the permissions necessary for their role and the customer or regulatory operation concerned.
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.
Backup and recovery
Production records should be backed up and recoverable according to their operational and regulatory importance.
Event and evidence linkage
Material compliance actions should be linkable to source data, account, time, country and resulting evidence.
Only data needed for the task
Integrations should avoid collecting consumer identity data where destination, parcel and SKU information is sufficient.
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 GDPR applies, Article 32 requires controller and processor security measures to take account of the state of the art, implementation costs, the nature, scope, context and purpose of processing and the likelihood and severity of risk to individuals.
Relevant controls can include, where appropriate, encryption and pseudonymisation, measures supporting confidentiality, integrity, availability and resilience, recovery capability, and regular evaluation of security controls.
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.
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.
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/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.
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.
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, PRO or system, the intended structure is to use a licensed PSP, safeguarded client-money arrangement or another legally compliant third-party payment model.
No specific PSP 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 · Current Tilda infrastructure
We distinguish today's website stack from tomorrow's production compliance stack.
The public website is currently operated using Tilda.
Tilda's DPA currently identifies:
- Hetzner Online GmbH — server storage;
- G-Core Labs SA — storage and backup of user projects;
- Google Cloud EMEA Limited — project information-security functions.
Tilda's published DPA also describes cross-border processing and its use of transfer safeguards. Its own current DPA should be consulted for the authoritative list and terms applicable to Tilda infrastructure.
We do not extrapolate those controls into unsupported claims about a separate Beyoğlu production system.
9 · Providers and subprocessors
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 a Beyoğlu subprocessor.
10 · International data transfers
We do not describe Turkish processing as an intra-EU transfer.
The current operational 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, the applicable mechanism may therefore include Standard Contractual Clauses and supplementary safeguards, depending on the processing relationship.
See the Privacy Policy for further information.
11 · Security incidents
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 GDPR applies, a reportable personal-data breach must be notified to the competent supervisory authority without undue delay and, where feasible, within 72 hours after the controller becomes aware of it, unless the breach is unlikely to result in risk to 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.
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, applicable timestamps and later submission evidence where operationally relevant.
13 · Customer responsibilities
A secure platform cannot compensate for compromised customer credentials.
- protect account credentials and API secrets;
- use separate authorised user accounts where provided;
- remove access from users who no longer require it;
- protect the customer's own commerce and ERP systems;
- transmit only the data necessary for the compliance purpose;
- notify Beyoğlu promptly of suspected compromise;
- maintain accurate product and packaging source data.
14 · Certifications and claims
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 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 secrets in a public channel.
Report a security concern