Data Classification and Protection Strategies

Data classification is the process of organising data into groups based on how sensitive it is and how much harm would be caused if it leaked. Think of it as putting a label on every file, database row, and email that says “Public,” “Internal,” “Confidential,” or “Restricted.” Once data has a label, you can decide what protection to apply. A “Public” marketing brochure might need no encryption, but a “Restricted” patient health record must be encrypted at rest (when stored) and in transit (when sent over a network).

Google Cloud provides several tools for this. The first is Cloud DLP (Data Loss Prevention). Cloud DLP scans your data for sensitive patterns — things like credit card numbers, passport IDs, Social Security numbers, or API keys. Once it finds them, it can do three things: it can redact them (remove them), mask them (show only the last four digits), or tokenise them (replace the sensitive value with a random token that still works in your system but is useless to an attacker). For example, if you have a database column called “customer_email,” Cloud DLP can detect that every value looks like an email address, then automatically replace each email with a random string like “abc123@token.com” so that the original addresses are never exposed in your logs or analytics datasets.

The second major tool is Cloud KMS (Key Management Service). Cloud KMS is a centralised place where you create, store, and control cryptographic keys. A key is a long string of random numbers and letters that acts like a password to scramble your data. When you encrypt a file, you run it through an algorithm (like AES-256) with a key, and the output is unreadable without that same key. Cloud KMS lets you define which keys are used for which data. You can give a key to one team but not another. You can set a key to automatically expire after 30 days. You can also use “customer-managed encryption keys” (CMEK), meaning Google does not control the key — you do. If you need even more control, you can bring your own encryption key (CSEK) and manage it outside Google Cloud entirely.

Why does this matter? Before the cloud, companies stored files in a filing cabinet and relied on the building security guard. If someone walked out with a paper file, nobody knew. In the cloud, data moves across many services — from a database to a data warehouse to an analytics dashboard — and a single mistake (like copying a database row into a log file) can expose millions of customer records. Classification and encryption ensure that even if a mistake happens, the data is still protected.

Protection strategies also involve defining retention rules and deletion policies. You cannot protect what you never delete. Google Cloud’s DLP and KMS work alongside services like Cloud Storage Object Lifecycle Management, which can automatically delete objects after a set period. A complete strategy tells the system:

The PCSE exam expects you to know the difference between encryption at rest, encryption in transit, and encryption in use (where data is processed while still encrypted — a newer concept). You also need to know that not all data needs the strongest encryption: classifying data first saves money because stronger encryption uses more compute resources. You should be able to choose between Cloud DLP’s techniques (redaction, masking, tokenisation) for a given scenario, and explain when to use CMEK instead of CSEK or google-managed keys.

A medium-sized healthcare SaaS company, MediTrack, stores patient appointment records, billing information, and internal employee emails in Google Cloud. They are preparing for a HIPAA (healthcare privacy law) audit and need to prove they protect “protected health information” (PHI). The IT security lead, Priya, follows this step-by-step procedure to build a data classification and protection strategy.

First, Priya maps data flows. She lists every service that holds data: a Cloud SQL database for patient records, a Cloud Storage bucket for scanned documents, and BigQuery tables for analytics. She also includes logs that might accidentally capture PHI. She uses “Cloud Asset Inventory” to discover all resources in the project.

Second, she runs Cloud DLP inspection jobs on each source. She creates a DLP job configuration that includes built-in infoTypes for medical record numbers (MRN) and health insurance IDs. The job scans 100,000 rows in Cloud SQL. It finds 400 rows that contain MRN patterns. Cloud DLP also finds 12 rows with credit card numbers in a notes column where they should not be.

Third, Priya classifies the data based on DLP results. She labels the Cloud SQL database “Confidential — PHI” using a data labelling tool called Google Cloud Data Catalog. She ensures that any new table created in the project is automatically inspected by a DLP job.

Fourth, she encrypts the data at rest. The Cloud SQL database already uses Google-managed encryption keys by default. But for the “Confidential” classification, Priya creates a CMEK in Cloud KMS, rotates it every 90 days, and restricts access to the key to only two senior engineers. She also enables encryption in transit by forcing all database connections to use TLS 1.3.

Fifth, she sets access controls. She creates IAM (Identity and Access Management) roles that grant “Cloud KMS CryptoKey Decrypter” only to the application’s service account, not to any human. She writes a DLP de-identification template that automatically redacts phone numbers and patient names from any log export, ensuring logs never contain PHI.

Sixth, she configures lifecycle policies. The Cloud Storage bucket holding scanned documents automatically moves objects older than one year to “Archive storage” class (lower cost, longer retrieval time) and deletes them after seven years, using a bucket lock that prevents anyone from shortening the retention period.

Finally, she runs weekly DLP scans and sends findings to Cloud Logging, with an alert if any new sensitive data is found in a previously clean bucket. The company passes the HIPAA audit because they can demonstrate: classification labels, encryption with customer-managed keys, automated DLP scanning, and strict access logging.

What does Priya actually do day-to-day? She tweaks DLP templates when new types of sensitive data appear (like new credit card formats). She monitors key rotation schedules in Cloud KMS. She reviews IAM policy changes to ensure no unauthorised person has decryption permission. She also creates reports for the compliance officer showing how many records are classified at each level and what percentage have encryption enabled.