Chapter 7 — Data Protection and Compliance: CASB, DLP, and Cloud App Control

Most of a user's day happens in the cloud — Microsoft 365, Salesforce, Slack, ServiceNow, generative-AI assistants, and a long tail of tools nobody in IT formally approved. Where the secure web gateway, ZTNA, and firewall-as-a-service decide whether a user or device may reach a resource, CASB and DLP govern what happens to the data once traffic is flowing. Cisco Secure Access is a cloud-delivered Security Service Edge (SSE) platform, and within it CASB is the policy enforcement point between users and cloud services — SaaS, web apps, and generative AI. The CASB component is powered by Cisco Umbrella, which supplies application discovery, risk scoring, and SaaS API integrations.

Think of CASB as a customs checkpoint at a busy international airport. Travelers (users) constantly cross a border into foreign territory (cloud apps). Without a checkpoint, anyone could carry anything across in either direction and no record would exist. CASB installs the checkpoint: it logs who crosses, into which country, and — with DLP — inspects what is in their bags.

Cloud app discovery and risk scoring

Every DNS query and HTTP/HTTPS request through Umbrella is logged and classified into a specific application, surfaced under views such as Reporting > App Discovery. Because Secure Access correlates that usage with identities and groups from your IdP, activity ties not just to an app but to specific users or departments. CASB addresses Shadow IT three ways: App Discovery dashboards reveal discovered and flagged apps by risk and category; risk-based classification assigns each app a profile from business risk, reputation, and usage type; and app groups and categories ("File storage," "Generative AI," "Social media") let policy apply per category or risk level.

Worked example. An analyst opens App Discovery and sees a spike to an unrecognized file-sharing domain: 34 Sales users, ~2 GB uploaded over the weekend, and a high risk score from poor reputation and a "consumer file storage" usage type. Rather than an all-hands email, the analyst adds the app to a high-risk group and attaches a policy — discovery, attribution, scoring, and decision all inside one console.

Tenant controls and app blocking

Once apps are discovered and scored, CASB acts as an intermediary enforcing usage policy through three broad types: app access policies (detect, report on, and block selected apps including generative AI); risk-based policies (attach risk profiles so you can express "block all apps with risk score ≥ X"); and OAuth app controls (discover, block, and revoke risky third-party plug-ins inside Microsoft 365 and Google Workspace by revoking their OAuth tokens). Enforcement happens at several layers — DNS/SWG inline blocking, per-transaction controls (allow login but block file upload; allow view but block download/share), and token revocation reaching directly into the SaaS tenant.

Inline vs. API CASB

CASB is delivered in two architectural modes, and this split is the single most important concept in the chapter because DLP inherits it. Inline (proxy-based) CASB reroutes traffic through a proxy between users and cloud apps, inspecting data in motion and enforcing policy synchronously — so a prohibited action can be stopped before it completes. The trade-off: traffic steering is mandatory, and anything that bypasses the proxy (a native mobile app, a thick client, an unmanaged home device) is invisible to it. API-based (out-of-band) CASB integrates directly with sanctioned SaaS tenants via their APIs, reading events, files, and configuration inside the tenant without being on the network path. It sees all access paths plus historic data at rest, but enforcement is asynchronous — arriving seconds after an action. Cisco packages the combined dual approach as "multimode DLP."

Figure 7.1: Shadow-IT discovery-to-control workflow

Figure 7.2: Inline (proxy) vs. API-based CASB/DLP interception paths

If CASB decides which apps users may touch, DLP decides which data may move. Cisco integrates DLP with CASB and SWG to inspect content and files for sensitive data both in motion (inline) and at rest via SaaS APIs. In the airport analogy: CASB is the passport-control officer deciding who may cross; DLP is the baggage scanner looking inside every bag — recognizing contraband using templates and fingerprints called data identifiers.

Predefined data identifiers

A DLP engine cannot block "sensitive data" in the abstract; it needs a precise definition. Predefined identifiers and templates cover common regulatory/PII patterns and industry-specific templates. Pattern-based identifiers use regex plus context (a 16-digit number preceded by "Visa" and followed by an expiry date). Exact data match / fingerprinting generates a fingerprint of a specific dataset and uses it as an identifier — how you protect a customer list or pricing table with precision. Under the hood: regex, Luhn checksum validation, contextual keyword rules, and dictionaries.

Worked example. Your team exports the customer database; DLP fingerprints it. Later an employee tries to upload a matching CSV to personal cloud storage or paste it into a generative-AI tool. DLP flags the fingerprint match and CASB blocks the upload — the fingerprint matches your data specifically, where a generic PII pattern might miss a de-identified export or over-match an unrelated spreadsheet.

Figure 7.3: DLP inspection and enforcement decision flow

Inline DLP policy enforcement

Inline DLP works with the SWG/CASB proxy to protect data in motion. When users upload files or submit forms, traffic is inspected for PII, PCI, or confidential documents via full file content inspection at upload time. A violating transaction can be blocked, allowed-but-logged, or made to require justification — all synchronously. Because inline DLP applies to essentially any web app where a user can input, download, share, or move data, it is the primary tool for controlling unsanctioned Shadow IT.

Worked example. A user tries to upload a spreadsheet with 50 credit-card numbers to an unsanctioned file-sharing app. Inline DLP inspects the upload, detects Luhn-valid PANs plus context, and blocks the transfer — the data never left the organization. Meanwhile API-based DLP handles data already at rest: after being granted API permissions to a tenant, it scans files and finds violations such as an HR-records folder shared publicly on OneDrive, then changes sharing to internal-only or quarantines the files (monitor, quarantine, or revoke access).

Inline vs. API-based DLP — side by side

Favor inline DLP when you must prevent exfiltration at the moment of action or need broad coverage across many web apps without onboarding each API. Favor API-based DLP for compliance-grade governance of a sanctioned tenant's entire content store, including access paths (mobile, sync clients) that never touch the proxy.

Handling regulated data (PII, PCI, PHI)

The three categories map to three detection strategies. PII (GDPR "personal data") — pattern-based identifiers for emails, phones, and national IDs, reinforced by context ("customer ID," "passport"). PCI cardholder data — regex for 13–19 digit numbers, Luhn validation, card-brand prefixes, plus context ("PAN," "CVV") and composite rules requiring N valid PANs. PHI/ePHI — hardest, lives in free text; relies on medical-terminology dictionaries, HIPAA's 18 identifiers, and heuristics ("diagnosis," "discharge summary"). Across all three: start in monitor-only mode and tune before promoting to block.

The technical controls of the previous sections exist because regulators demand them. Cisco Secure Access supports PCI-DSS, HIPAA, and GDPR by combining zero-trust access, CASB, and DLP/data classification to discover and control regulated data (PII, PCI, PHI) and to enforce the access, monitoring, and protection controls those regulations require. Across all three, a small set of obligations recurs: identify and classify sensitive data, limit access via least privilege and strong authentication, protect data in transit and at rest, monitor and log access, and detect and prevent exfiltration.

PCI-DSS mapping

PCI-DSS organizes into 12 requirement areas emphasizing access control, encryption, logging, and data protection for cardholder data.

A critical nuance: PCI-DSS does not certify a product alone as "PCI compliant" for a merchant. Secure Access provides controls and evidence that form part of a broader posture.

HIPAA mapping

The Security Rule defines administrative, physical, and technical safeguards for ePHI; several technical safeguards map directly to SSE/CASB/DLP controls.

GDPR mapping

GDPR emphasizes data protection by design and by default, data minimization, secure processing, and accountability.

Audit, reporting, residency, and the caveat

The common thread is evidence. Auditors do not accept "we have DLP" — they want to see the control operated. Secure Access centralizes CASB and DLP logs so you can build framework-aligned reports ("all blocked transfers of cardholder data to non-PCI apps," "all PHI transfer attempts to non-BAA cloud services"). A repeatable deployment pattern: (1) define regulatory scope and data types; (2) discover cloud usage and tag in-scope apps; (3) enable and tune DLP identifiers; (4) create compliance-driven policies; (5) integrate identity and MFA via Duo; (6) centralize logging and build auditor-facing reports; (7) iterate.

Two edge considerations: data residency (the SSE deployment itself must meet residency/cross-border obligations, including where inspection logs live) and scope beyond web/SaaS (databases and on-prem EHR need complementary controls like segmentation and encryption). This leads to the most important caveat in the chapter: tools enable compliance; they do not guarantee it. BAAs, staff training, process controls, and residency handling remain the organization's responsibility — Secure Access is a major part of the architecture, not the whole of it.