Security used to be the department that said no. Now it’s the reason customers say yes. Because every data conversation eventually reaches ‘and how is this protected?’
This category covers the protective layer around data systems. The terms 👇
30-Second Summary
Security and compliance terms cover how data systems get protected: securing data at scale, authenticating both ends of a connection, and managing who is allowed to access what.
What This Category Covers
- Protection at scale: big data security
- Trusted connections: mTLS
- Who gets in: identity management
📌 Quick take: Most breaches aren't exotic. They're an identity nobody deprovisioned or a connection nobody verified. The boring controls are the ones that matter.
The Terms in This Category, Walked Through
Big data security adapts protection to platforms where scale multiplies everything. The page hardens each layer in turn. Storage, compute, ingestion, catalog. Then it covers the access-control patterns that survive thousands of identities and datasets. Attribute-based policies, column security, time-boxed elevation, quarterly recertification.
And it makes one big detection shift. Stop watching doors. Start watching usage. Because at scale, exfiltration looks like a legitimate account running one very large query. Its compliance section covers the capability to build early. Prove, from logs, whose data lived where. And show that deletion took.
mTLS goes deep on the trust mechanics of machine-to-machine communication. Both endpoints prove identity cryptographically before data flows. The page covers the PKI machinery underneath (private authorities, short-lived certificates, automated rotation) and the service-mesh era that made mutual authentication an infrastructure default.
Just as usefully, it shows where NOT to use it. And the debugging field guide at the end belongs in every integration runbook. Verbatim.
Then identity management is the discipline every incident narrative eventually features. Authentication, authorization, and the joiner-mover-leaver lifecycle. The ‘mover’ step is where least privilege quietly dies.
The page also covers the machine-identity population that now outnumbers humans. It treats federation and single sign-on as a concentration of both convenience and risk. Zero trust? That’s IAM promoted to perimeter. And there’s a 90-day improvement plan for teams starting from sprawl.
How the Three Compose
They stack. Identity management decides WHO may act, human or machine. mTLS proves those identities to each other at connection time. And big-data-security’s policies and monitors govern what the proven identities may do inside the platform, with masking from the neighboring folder deciding what they see.
A request touching sensitive data crosses all three pages. In milliseconds. So your security posture is exactly as strong as the weakest crossing.
The folder’s shared conviction, earned in every postmortem: the boring controls dominate. Not exotic attacks. Over-permissioned accounts, expired certificates, world-readable buckets. Accumulation and drift, not brilliance. And the countermeasures are just as unglamorous: inventories, rotations, recertifications, and monitors, run on calendars rather than adrenaline.
Using This Folder
Securing a data platform from scratch? Read big data security for the map. Then identity management for the control plane it presumes. Then mTLS when service-to-service and partner connections arrive.
Preparing for an audit instead? Every page’s checklist sections translate directly into evidence. And if you’re prioritizing under budget, each page names its highest-blast-radius fixes first. Start there. Let the sophistication follow the fundamentals.
Questions This Category Answers
“Where would a breach actually start?” The folder’s collective answer, earned across postmortems: an identity. Over-permissioned, orphaned, or stolen. The IAM page’s lifecycle machine and 90-day plan target exactly that surface.
“How do services trust each other?” mTLS: both endpoints proving identity cryptographically before data flows. Plus the certificate-lifecycle automation that keeps the trust from expiring on a Saturday.
“How do we secure a platform that everyone needs access to?” The big data security page’s answer: fine-grained policies over platform-wide keys, masking for the sensitive remainder, and behavioral monitoring. Because at scale, the breach looks like a legitimate account doing something new.
“Can we prove it to an auditor?” Each page’s controls double as evidence. Recertification records, certificate inventories, access logs, and the whose-data-lived-where capability designed in before the question arrives.
“What do we fix first with a small budget?” Every page names its blast-radius ordering: bucket audits, credential hygiene, leaver pipelines, logging. The unglamorous fixes that close the doors attackers actually use.
The folder’s posture in one line: calendars beat adrenaline. Security run as inventories, rotations, and reviews on schedule is what ‘strong posture’ actually looks like from inside.
How This Category Connects to the Rest of the Wiki
Security is the property the rest of the wiki assumes. The transfer and pipeline pages assume authenticated endpoints, and this folder’s mTLS provides them. The analytics platforms assume governed access, and IAM enforces it. And the enterprise platforms assume audit trails, which this folder’s disciplines produce. Strip this category out and every other page’s happy path quietly stops being safe.
Its closest partnership is next door. Data Protection & Privacy decides what protected data should look like. This folder decides who reaches it, and proves who did. Together they form the estate’s control plane: techniques and enforcement, two folders, one posture.
And the cultural note that makes the whole category work: security succeeds when it’s the paved road, not the toll gate. Automatic certificate rotation. Role templates that provision on day one. Masked data that’s easier to get than production copies. Every page here, read carefully, is about making the safe path the convenient path. That design stance, more than any control, separates estates that stay secure from estates that stay lucky.
Start Here If You’re New
The approachable entry is identity management. You’ve experienced good and bad access management yourself, so the joiner-mover-leaver frame organizes intuition fast. mTLS comes second, for the machine-to-machine trust modern integration assumes. Big data security comes last. Save it until the platform vocabulary from neighboring folders feels comfortable.
Under audit pressure? Reverse it. Big data security’s evidence sections first, then IAM’s recertification machinery, then the certificate inventory disciplines. Auditors follow nearly the same path. Arriving prepared means walking it before they do.
Both paths converge on the folder’s core belief: security is a property of routines, not a department or a product. The pages supply the routines. The calendar supplies the rest.
Frequently Asked Questions
What is data security and compliance?
Security is protecting data systems from unauthorized access; compliance is proving that protection to auditors and regulators. The same controls serve both: access policies, logs, and inventories double as evidence.
What causes most data breaches?
Unglamorous drift: over-permissioned accounts nobody deprovisioned, expired certificates, and world-readable storage. Exotic attacks make headlines, but identity and configuration failures do most of the damage.
What is the difference between identity management and mTLS?
Identity management decides who is allowed to act, human or machine. mTLS proves those identities to each other at connection time. One is the control plane, the other is the handshake that enforces it between services.
Where should a small team start with security?
With the highest-blast-radius basics: audit storage permissions, rotate credentials, build a leaver pipeline, and turn on access logging. Run them on a calendar, not on adrenaline. Routine is what strong posture actually looks like.