When the date for a KVKK (Turkish data-protection) audit is set, the first question IT faces is rarely technical: "Where do we hold the data?" In a modern organisation, the answer is not one sentence — there is data in Salesforce, in Notion pages, a customer ID number may have been discussed in a Slack channel, a finance team's Excel may have been shared via Google Drive. KVKK asks where personal data lives and what it is processed for; in the SaaS world, this question is almost always unanswered because there is no inventory.
This piece explains why the KVKK + SaaS equation starts with inventory, what the practical steps for RoPA (Records of Processing Activities) preparation are, and how the same inventory can serve KVKK + ISO 27001 + NIST CSF alignment at once.
KVKK's real scope: SaaS included
Under KVKK's formal definition, the "data controller" is responsible for every system in which personal data is processed. In practice, SaaS applications fall squarely in scope:
- CRM (Salesforce, HubSpot) — customer personal data
- HR (BambooHR, Workday, payroll tools) — employee data
- Communication (Slack, Teams, Zoom) — messages containing personal data
- File storage (Drive, OneDrive, Dropbox) — customer contracts, employee files
- Marketing (Mailchimp, ActiveCampaign) — personal communication lists
- Support (Intercom, Zendesk) — customer conversation history
The RoPA must cover every one of these. Most organisations prepare a RoPA limited to on-premise systems; the SaaS gap shows up at audit time.
Three core data points for RoPA
For each application, RoPA requires:
1. Data class
What category of personal data is processed here? KVKK explicitly separates special-category data (health, biometric, religion, union membership, judicial decisions). Even for general personal data, the RoPA must record the category.
2. Data location
Is the data in the EU, the US, or another region? KVKK applies separate controls to cross-border transfer. The provider's data-centre location and transfer paths must be documented.
3. Data subject rights
How do we honour access, deletion, portability? The provider must support DSR (Data Subject Request) processes. The RoPA must capture how each request is fulfilled.
One inventory, three frameworks
An organisation that passes KVKK should, in principle, be ready for ISO 27001 and NIST Cybersecurity Framework on the same foundation. In practice, each framework looks at the same pieces of data with different names:
- KVKK → data controller inventory, RoPA, cross-border transfer, explicit consent.
- ISO 27001 → asset inventory (A.5.9), supplier security (A.5.19–21), access control (A.5.15).
- NIST CSF 2.0 → ID.AM (Asset Management), ID.SC (Supply Chain), PR.AA (Identity Management, Authentication, and Access Control).
All three ask the same questions: which SaaS apps, processing what data, who has access, what is the third-party risk. CenseCloud produces a unified report output for all three frameworks — one inventory feeds three audits.
Three most common mistakes in KVKK preparation
- 1. Starting only from finance data. Apps bought on a non-IT team's corporate card don't show up in finance, and are the largest RoPA gaps.
- 2. Treating the SSO list as the inventory. There are dozens of apps that process personal data without being integrated to SSO.
- 3. Treating RoPA as a one-time project. The SaaS portfolio drifts 3–5% per month. A static RoPA is invalid at the next audit; it must be continuously refreshed.
Conclusion: inventory is the foundation of the compliance you publish
Passing a KVKK audit is not a technical project, it's an ongoing practice. The core practice is SaaS inventory — you can't make an app you can't see compliant.
CenseCloud delivers the KVKK risk layer + RoPA output + three-framework alignment from one inventory. See the risk & compliance solution or the CenseRisk module for details.