FAQ · Data security
Data security, KVKK & recipient manifest handling
A practitioner's view of how a corporate merch programme handles personally identifiable information: recipient manifests, KVKK (Türkiye's personal data protection law) compliance posture, GDPR Article 28 alignment, sub-processor management, retention periods, breach notification duties, and the vendor-selection criteria that audit teams look for during a procurement review.
Why data security is now a routine vendor-evaluation gate
Three years ago, vendor questionnaires on data security were a 5-question afterthought at the bottom of a procurement RFP. Today, the same RFP carries a dedicated Annex C with 40-80 questions covering data residency, encryption, sub-processors, breach notification, audit rights, retention, lawful basis, and data subject rights. The reason is two-fold: KVKK (Kişisel Verilerin Korunması Kanunu, Turkish Personal Data Protection Law No. 6698, in force since 2016 with subsequent amendments aligned with GDPR) has sharpened the compliance posture of corporate buyers; and the average cost of a personal-data breach for B2B services has crossed seven figures, which makes the vendor a financial exposure they cannot ignore.
The practical consequences are visible in every supplier relationship on merch.org.tr. The standard corporate merch order requires the operator to handle a recipient manifest — names, emails, departments, size information, sometimes delivery addresses. That manifest is personal data under both KVKK and GDPR (assuming EU/EEA recipients), with all the obligations that follow: lawful basis, processing limitation, retention discipline, sub-processor disclosure, and breach notification within 72 hours (KVKK Article 12 / GDPR Article 33). Programmes that don't get this right end up facing fines, contract clawbacks, and audit findings that can take 6-18 months to remediate.
Where recipient data lives: KVKK, GDPR, and the dual-resident pattern
The classical question is "where is the data stored?" For Turkish-originated merch programmes serving Turkish recipients, the answer is straightforward: data centres within Türkiye, per KVKK Article 9's principle of data being processed within the country's borders where required. For cross-border programmes — the usual case for multinationals based in Istanbul with regional offices in the EU, GCC, or Central Asia — the data residency pattern follows the recipient's jurisdiction, not the supplier's. This produces a multi-resident setup: Turkish recipients on Türkiye-resident infrastructure (typically İstanbul-based providers like Türk Telekom, Turkcell, or AWS / Azure Türkiye regions when available), EU recipients on EU-resident infrastructure (Frankfurt, Amsterdam, Dublin, Stockholm), UK recipients on UK-resident (London) post-Brexit.
Encryption is the second layer. At-rest encryption is AES-256 minimum, with key management handled by a dedicated KMS (Key Management Service) rather than embedded in the application layer. In-transit encryption is TLS 1.3 with strict cipher ordering and HSTS enforced. End-to-end encryption (E2EE) for the recipient manifest itself is reserved for high-sensitivity programmes — defence, public sector, healthcare-adjacent — where the manifest content carries extra disclosure risk. For the typical corporate merch manifest, at-rest + in-transit is the right answer; E2EE adds operational complexity that rarely clears a cost-benefit test.
Access control is the third layer. Recipient manifests should never be shared by email or unencrypted spreadsheet; the standard pattern is a role-based access control (RBAC) inside a vendor portal where each operator sees only the recipients relevant to their task. Audit logging is mandatory — every access, every change, every export is logged with a tamper-evident signature and retained for the longer of (the audit requirement) or (12 months). Programmes that fail this layer tend to fail via shared spreadsheets with the recipient list emailed around a multi-stakeholder distribution team; the fix is to centralise the manifest in the supplier's portal from day one.
KVKK compliance mechanics: VERBİS registration, masking, and data-subject rights
Türkiye's KVKK establishes a Personal Data Protection Board (Kişisel Verileri Koruma Kurumu, KVKK Kurumu) that maintains a registry of data controllers (VERBİS) and oversees enforcement. Data controllers processing sensitive personal data or large-scale personal data must register with VERBİS; corporate merch operators handling >1000 recipient records per year commonly meet the threshold. Registration is via the VERBİS portal with categories of data, processing purposes, retention periods, and cross-border transfer safeguards. The annual disclosure obligation for data controllers above the size threshold is 31 March / 30 June cycle — operators missing the deadline face administrative fines up to TL 1 million (~EUR 28,000 at current rates).
Data masking is the standard approach for non-operational uses of the recipient manifest. After the production window closes (typically 30-60 days for personalization, 90 days for QA), the manifest is masked: names → initials, emails → anonymised hashes, addresses → region-level only. This permits post-production statistical reporting (e.g., "delivered vs returned", "department-wise recipient counts") without continuing to expose personal data. The masking pattern must be implemented at the storage layer rather than the application layer to prevent accidental unmasking through data export.
Data-subject rights under KVKK Article 11 align closely with GDPR Articles 15-22: right to information, right of access, right to rectification, right to erasure (where lawful basis no longer applies), right to object, right to data portability. For corporate merch programmes, the typical exercise of these rights looks like: an employee asks their employer to delete their manifest record (left the company, no longer wants merch communications); the employer escalates to the merch vendor; the vendor confirms deletion within 30 days (KVKK's statutory window) and provides a deletion certificate. Operators without a documented workflow for this typically take 60-90 days and miss the deadline. Build the workflow into the contract, not the response.
Sub-processor management: who else sees the data
Every data controller has sub-processors — vendors that touch the data on the controller's behalf. For a corporate merch operator, the typical sub-processor chain runs: merchandise supplier → decoration printer → kitting/fulfilment warehouse → last-mile courier → IT hosting provider → email / marketing automation (for recipient communications). Each is a sub-processor under KVKK Article 12 / GDPR Article 28. Each requires a written data processing agreement (DPA) with the controller's instructed scope, the recipient data categories permitted, retention limits, sub-processor disclosure, security obligations, audit rights, and breach notification timelines.
The vendor's due diligence on sub-processors should verify: (a) the sub-processor has its own DPA-ready template backed by appropriate security certifications (ISO 27001, SOC 2 Type II, or sector-specific equivalents); (b) the sub-processor's processing is geographically within the controller's permitted jurisdictions (no surprise processing in non-adequate jurisdictions); (c) the sub-processor maintains its own breach notification obligation back to the controller; (d) the controller has the right to audit the sub-processor's processing under NDA. For EU-resident data sub-processors in non-adequate jurisdictions (notably US-resident sub-processors post-Schrems II), additional safeguards like Standard Contractual Clauses (SCCs) with Transfer Impact Assessment (TIA) are required.
A practical operator challenge is keeping the sub-processor map current — sub-processors change over time as the operator's stack evolves. The standard practice is a published sub-processor list (refreshed quarterly or on any change) with a 30-day notice period before a new sub-processor starts processing. Subscribers to that list — typically the controller's procurement and legal teams — review the change and either consent or object within the window. We've seen programmes stall for 60+ days because the sub-processor change notification didn't reach the right stakeholders; the fix is to build the notification into the controller's onboarding flow from the outset, with a named escalation contact on each side.
Retention, deletion, and the manifest lifecycle
The manifest has a defined lifecycle, not an open-ended retention. Production phase (typically 30-60 days for personalized merch, up to 90 for complex multi-language packs) keeps the manifest live for production QA and shipping reconciliation. Post-production, the manifest is masked for statistical reporting and audit access for 7 years (matching the Turkish tax audit window for invoiced B2B transactions, and matching the EU GDPR record-keeping for accounting documents). After 7 years, the masked manifest is destroyed with a destruction certificate retained for 3 additional years.
Different categories of data have different retention rules. Production data — names, sizes, departments — is destroyed within 90 days of order completion (operator-specific deadlines tighten this to 30 days when personalisation is involved). Delivery data — addresses, courier tracking — is retained per the courier's own retention policy (usually 12-24 months for tax record purposes). Financial data — invoices, payment records, bank transfer references — is retained per the Turkish tax code (5 years commercial, 10 years for tax investigations). The exact retention schedule must be in the operator's KVKK registration and in the contract annexes.
Deletion at end of retention must be auditable. We issue a destruction certificate per data category per year, listing the dataset identifiers, the destruction date, the destruction method (cryptographic erasure, physical destruction of storage media, or secure overwrite), and a named witness. The certificate is retained internally for the operator's own audit purposes and is provided to the controller on request. Programmes without auditable deletion tend to have manifests hanging around in backup systems for years, which a KVKK audit or a GDPR-led DPA inquiry will catch quickly — the cure at that point is expensive (forced remediation, supervisory fine, and a public notice on the operator's record).
Breach protocol: 72-hour notification and the operator's role
Under KVKK Article 12, data controllers must notify the KVKK Kurumu within 72 hours of becoming aware of a personal-data breach — sometimes called "the quickest reasonable time" once aware, with a documented delay allowed under specific conditions. For EU GDPR equivalent, the controller must notify the supervisory authority within 72 hours under Article 33. For service providers (i.e., the merch supplier acting as processor), the obligation is to notify the controller without undue delay, with the controller responsible for the supervisory authority notification. The merch operator's contract should specify the breach notification window to the controller — best practice is "without undue delay, and in any case within 24 hours" — giving the controller the maximum available time to make its own 72-hour filing.
Tabletop exercises are the discipline that turns the protocol from paper to muscle memory. Quarterly, the operator walks through a credible breach scenario — for a merch programme, the typical scenarios are (a) lost courier parcel with a manifest inside, (b) compromised supplier portal credentials, (c) misconfigured cloud storage exposing manifest records, (d) third-party sub-processor breach where the controller's data is implicated. Each scenario is walked through: detection, triage, containment, notification, regulator liaison, communications to data subjects, post-mortem, and corrective action. We've run 14 such exercises over the past 5 years; the median time-to-contain has dropped from ~14 hours to ~3 hours as the playbook has matured.
The cyber insurance policy is the financial backstop. A typical policy covers notification cost, regulatory fines (where insurable), credit-monitoring for affected data subjects, public relations management, third-party liability, and the cost of forensic investigation. Limits of $2-10M are common for corporate merch operators; premiums are 0.15-0.4% of insured turnover. We maintain $5M+ cyber liability with a 24-hour breach hotline and named regulatory counsel; this isn't universal in the merch supplier universe, but it's a routine procurement requirement for corporate procurement teams that buy merch in meaningful volume and at named tier-1 supplier status.
Audit rights and SOC 2 / ISO 27001 expectations
Controllers (the buyer's procurement team) have the right to audit the merch operator's data processing. The contract typically provides for an annual audit, ad-hoc audits on reasonable notice (14 days minimum) following a breach or significant change, and a "right of inspection" — the controller can visit the operator's processing facilities, review documentation, interview staff, and check the controls in place. Operators that object to audit rights in principle rarely win the contract; the better posture is to facilitate audits cleanly. We've hosted 6 controller-led audits per year on average; the cost is about 8-16 hours of operator staff time and ~$2,000-4,000 in external audit support, but the deal value is several times that.
Third-party certifications smooth the audit path. ISO 27001 (Information Security Management Systems) is the global baseline; SOC 2 Type II (Service Organization Control, covering security, availability, processing integrity, confidentiality, privacy) is the US-flavored baseline and is increasingly requested by EU controllers as well. Operators that hold both certifications reduce the controller's audit burden substantially — the controller's procurement team can rely on the third-party assurance without re-running the entire control inventory. We've completed ISO 27001 certification and SOC 2 Type II audits; the certification cycle is annual with surveillance audits in between.
For Türkiye-resident processors, additional local standards apply. The TSE (Türk Standardları Enstitüsü) has sector-specific security certifications. The BTK (Bilgi Teknolojileri ve İletişim Kurumu) regulates certain categories of electronic communications data. The SPK (Sermaye Piyasası Kurulu) is relevant for finance-sector clients. Banking sector operators face the BRSA (Banking Regulation and Supervision Agency) additional requirements; healthcare sector operators face the TITCK (Turkish Medicines and Medical Devices Agency) controls. A corporate merch programme will pick up additional obligations based on the controller's industry; we maintain the layered compliance posture so that any single controller can be supported without gap.
Operator checklist: 10 things to verify before signing a merch DP contract
Before contracting, the controller should verify: (1) the operator's KVKK and GDPR registration posture; (2) whether the operator's standard DPA is controller-aligned or requires negotiation; (3) the sub-processor list and whether any are non-adequate-jurisdiction resident; (4) the encryption standards (at-rest, in-transit, key management); (5) the breach notification window (recommend "without undue delay, max 24 hours"); (6) the retention limits per data category; (7) the audit rights scope and frequency; (8) the data subject rights workflow including assignment of the controller's response lead time; (9) the cyber insurance coverage; (10) the operator's incident history (good operators will disclose proactively; transparent disclosure is a strong positive signal).
The list above is non-negotiable for high-sensitivity programmes (defence, public sector, healthcare, banking) and recommended as a baseline for any programme handling 1,000+ recipient records. We've seen procurement teams skip one or two of these items, only to face 3-6 month remediation projects when the audit cycle catches up. A controller's best practice is to capture the operator's responses in the procurement phase's Annex C and re-verify the responses in the contract review phase — anything that drifts in writing between those two reviews is a red flag.
The operator's side mirrors this: data security questionnaires completed and returned within the procurement deadline, a DPA template that doesn't require excessive redlining, a sub-processor disclosure that's complete and current, retention schedules aligned with the controller's statutory needs, and named escalation contacts (DPO, security lead, breach response lead) on the operator's side that are reachable 24/7 during the programme execution window. We've built these capabilities into a routine that completes 90%+ of corporate buyer questionnaires without follow-up — operators without this discipline typically experience 4-8 weeks of back-and-forth per major RFP, costing them the deal more often than not.
Get a data-security pack for your programme
Request the data-protection pack — DPA template, sub-processor list, retention schedule, breach protocol summary, ISO 27001 and SOC 2 Type II reports under NDA. We'll come back within one working day with the documents your procurement and legal teams need.