Security & Compliance

Security conversations in most companies follow a pattern: something goes wrong, the security team explains what happened, and everyone else nods along while privately translating the words into "it was some hacking thing." The translation is lossy. When you can't decode what a CISO is describing in a post-incident review, or when a vendor sends over their SOC2 report and you're not sure what you're looking at, the cost is real — slower decisions, misplaced trust, and a vague sense that security is the security team's problem rather than everyone's.

This guide is not a security practitioner's handbook. It's a business operator's working model — enough vocabulary and structure to participate in security conversations, evaluate vendors, understand compliance requirements, and know when to ask a smarter question.

We'll cover six areas. Identity and access management — who gets in and what they can see. Compliance frameworks — what SOC2 and its siblings actually mean. Privacy regulations — GDPR, CCPA, HIPAA, and why they affect you regardless of geography. The threat model — what attackers actually do. Vendor risk — how to tier and review the tools your team adopts. And zero trust — the architecture concept reshaping how companies think about the perimeter.

§1 The access control foundation: IAM Foundational

Every piece of software your company uses has to answer a version of the same question: is this person allowed to do what they're trying to do? Identity and access management (IAM) is the system, the policies, and the tooling that answers that question.

IAM has two distinct layers worth keeping separate.

Authentication is proving who you are. A password is the most common authentication factor — but passwords alone are weak because they can be stolen, guessed, or reused from other breaches. Multi-factor authentication (MFA) adds a second factor: something you have (a phone, a hardware key) or something you are (a biometric). An identity provider like Okta, Azure Active Directory, or Google Workspace is the centralized service that handles authentication for all of your company's applications — one login, many apps, audit trail in one place. Single sign-on (SSO) is the binding mechanism: one authentication event grants access across all linked applications without requiring separate logins per tool.

Authorization is what happens after authentication succeeds — what is this authenticated person allowed to see and do? Authorization is typically governed by role-based access control (RBAC), where access levels attach to roles (analyst, manager, admin) rather than to individual people. The foundational design principle is least privilege: give people the minimum access they need for their job, not the maximum that might be convenient. When a data analyst needs to read a table but not modify it, they get read access, not write access. When a contractor needs access to one system for three months, they get time-limited access to that system, not a permanent seat in the company directory.

Why does this matter to a non-security operator? Because access sprawl — people accumulating access they no longer need as their role changes — is one of the most common ways breaches spread once an attacker gets inside. The analyst who became a manager two years ago still has their analyst access plus their manager access. When their account is compromised, the attacker has both.

Related glossary: IAM, MFA, SSO, RBAC, identity provider, least privilege

§2 Compliance frameworks: SOC2, ISO 27001, and the language of audits Foundational

At some point in a B2B sales process, a prospect's security team will send a questionnaire. Near the top will be a variation of: "Do you have a SOC2 report?" If your answer is no, the deal may stall. Here's what SOC2 actually is — and why it matters beyond the sales motion.

SOC2 (Service Organization Control 2) is an audit framework developed by the American Institute of CPAs. It is not a certification you self-award — it's a report produced by an independent auditor evaluating whether a service organization's controls meet the Trust Service Criteria. There are five criteria. Security is the only mandatory one — every SOC2 audit covers it. The other four — Availability, Confidentiality, Processing Integrity, and Privacy — are added based on what the company and its customers care about. A payroll platform would include Confidentiality and Privacy. A cloud infrastructure provider would include Availability. Many early-stage SaaS companies pursue Security only.

The most important distinction for a buyer is Type I vs Type II. A Type I report is a point-in-time snapshot: the auditor assessed controls as of a specific date and found them suitably designed. A Type II report covers a period (typically 6–12 months) and found the controls not only designed correctly but operating effectively over time. Enterprise procurement teams generally require Type II — a snapshot doesn't tell you whether those controls were followed day to day.

ISO 27001 is the international equivalent — common in European enterprises and government procurement. It's a certifiable standard (you get a certificate, not just a report), broader in scope, and takes longer to achieve than a SOC2. PCI DSS (Payment Card Industry Data Security Standard) applies specifically to organizations that process payment card data — if your product touches a credit card number, PCI DSS compliance is required, full stop.

Related glossary: SOC2, ISO 27001, PCI DSS, audit, compliance

§3 Privacy regulations: GDPR, CCPA, and HIPAA Foundational

In May 2018, the EU's General Data Protection Regulation came into effect. Within hours, hundreds of services sent emails explaining their updated privacy policies — some thoughtful, most identical boilerplate, all legally motivated. GDPR created the template that most privacy regulation has followed since, and understanding its frame helps you read all of them.

The GDPR frame. GDPR applies to any organization processing the personal data of people in the European Union — regardless of where the organization is based. "Personal data" is broadly defined: names, email addresses, IP addresses, location data, device identifiers, behavioral data. The key concepts:

• Controller vs processor. The company that determines why and how data is processed is the data controller. A vendor they use to process that data is a data processor. If you use a third-party email platform to send marketing to your users, you're the controller; the platform is a processor. Both have legal obligations.
• Data subject rights. Under GDPR, individuals have the right to access their data, correct it, delete it (the "right to be forgotten"), restrict its processing, and take it with them (data portability). A Data Subject Access Request (DSAR) is the formal mechanism for invoking these rights. Organizations have 30 days to respond.
• Breach notification. Organizations must notify the relevant supervisory authority within 72 hours of discovering a breach that poses risk to individuals.

CCPA (California Consumer Privacy Act) is the primary US equivalent, applying to companies above certain revenue thresholds that collect personal information of California residents. Weaker than GDPR in some dimensions — there is no right to data portability — but increasingly the model for US state-level privacy legislation.

HIPAA covers protected health information (PHI) in the US healthcare context. Unlike GDPR's consent-and-rights model, HIPAA is sector-specific: any entity handling PHI (covered entities and their business associates) must meet specific technical, administrative, and physical safeguard requirements. The key operator implication: if your SaaS product touches PHI, you need a Business Associate Agreement (BAA) with every vendor in that data path — not just a standard DPA.

Related glossary: GDPR, CCPA, HIPAA, DSAR, PHI, BAA, data controller, data processor

§4 The threat model: what attackers actually do Building

The mental model most business operators carry about security threats is shaped by news coverage — sophisticated nation-state actors, elaborate zero-day exploits, dramatic heist-movie break-ins. The reality of attacks that hit most companies is considerably more mundane, and understanding what's actually happening makes the defenses make more sense.

Phishing is the dominant initial-access vector for most breaches. A phishing email looks like something legitimate — an invoice, a password reset, a notification from a service the target uses — and tricks the recipient into clicking a link that captures their credentials or opening an attachment that installs malware. Spear phishing targets specific individuals with personalized detail: their name, their manager's name, a real project they're working on. The sophistication of the social engineering varies; the principle is consistent — the attack is aimed at the human, not the system.

Credential stuffing exploits password reuse across services. When a breach at one service exposes username-password pairs, automated tools try those same credentials against hundreds of other services. If someone reuses their LinkedIn password for their corporate email, a LinkedIn breach becomes a corporate breach.

Ransomware is now a dominant attack type for its economic model: attackers encrypt files and demand payment for the decryption key, often threatening to publish exfiltrated data if payment doesn't come. The operational cost of a ransomware attack typically exceeds the ransom — downtime, recovery work, forensic investigation, regulatory notifications.

Data exfiltration is the quieter version: attackers get inside a system and take data without announcing themselves. The goal is usually valuable intellectual property, customer PII that can be sold or used for fraud, or credentials that enable further attacks elsewhere.

Supply-chain attacks target the software you trust rather than your systems directly. The 2020 SolarWinds attack inserted malicious code into a software update that tens of thousands of organizations automatically deployed. Your security posture is partly a function of the security posture of every vendor whose code runs in your environment.

Related glossary: phishing, spear phishing, ransomware, credential stuffing, MFA, social engineering

§5 Vendor risk: third-party access to your data Building

Every SaaS tool your company adopts is now part of your security perimeter. The CRM, the data pipeline, the HR system, the productivity suite — each one has access to your company's data or systems, and each one represents a potential breach vector if their security posture fails or if you haven't governed what they can access.

Third-party risk management (TPRM) is the practice of assessing and monitoring vendor security posture before and after procurement. The word "management" is doing real work — it's not a one-time review at signup, but an ongoing relationship.

Tiering the risk. Not every vendor deserves the same scrutiny. The useful frame is data sensitivity (what kind of data does this vendor touch?) crossed with access level (how much of your systems can they reach?). A tool that handles high-sensitivity data with broad system access — a data warehouse, a security monitoring platform — deserves a full security review. A tool with no sensitive data and minimal access — a design collaboration tool with anonymous exports — deserves a quick check.

What a full security review looks like. For high-tier vendors: review their SOC2 Type II (scope, period, exceptions); complete or request a security questionnaire; evaluate their data processing agreement (DPA); check contract clauses covering breach notification timelines (ideally ≤72 hours, matching GDPR), right to audit, and data deletion on contract termination. For mid-tier vendors: confirm SOC2 existence and period, read the DPA, confirm breach notification terms.

Sub-processor visibility. When a vendor processes your data, they often use other services to do it. Under GDPR you're entitled to know who those sub-processors are. A vendor's DPA should list them or link to a maintained page. Undisclosed changes in sub-processors are a flag worth raising.

Related glossary: TPRM, SOC2, DPA, vendor risk, sub-processor

§6 Zero trust: where the field is heading Strategic

The phrase zero trust appears on more security vendor marketing materials than almost any other term in the field — which has done a thorough job of obscuring something genuinely useful. Here's what it actually means, and why it matters even if you never buy a product that uses the word.

The perimeter model. Traditional network security was built around a perimeter: the company's office network was inside, the internet was outside, and the firewall kept the two separate. Once inside the perimeter — via the office network or VPN — you were trusted. Systems talked to each other freely. Employees accessed internal tools without re-authentication because they were "inside the building."

This model worked when offices were the primary workplace, applications ran on-premise, and contractors came to the building. It started breaking down as those assumptions changed: cloud applications live outside the perimeter by definition; remote work means employees access internal tools from home networks and coffee shop wifi; SaaS vendors need access to internal data; contractors operate from unknown environments. The "inside = trusted" assumption stopped being true.

Zero trust flips the assumption. "Never trust, always verify" is the principle. No implicit trust is granted based on network location. Every access request is authenticated and authorized in context — who is this person, on what device, from what location, accessing what resource? The identity is the perimeter, not the network edge.

What this means in practice:

• MFA everywhere, not just at the VPN login.
• Context-aware access policies — an employee logging in from an unmanaged personal device in a new country gets a different access decision than the same employee on a managed corporate laptop from their home office.
• Just-in-time access for privileged operations — rather than granting someone permanent admin access, grant it for the duration of a specific task and revoke it when done.
• Micro-segmentation — systems and services only communicate with the services they explicitly need, reducing the blast radius when a compromise occurs.

The direction zero trust points is irreversible. The shift to cloud, SaaS, remote work, and contractors makes the perimeter model increasingly incoherent. Zero trust is the vocabulary for the replacement architecture. You don't need to implement it all at once — but understanding what it means helps you ask better questions when your security team is making decisions about tools, policies, and access reviews.

Related glossary: zero trust, MFA, SSO, IAM, VPN, micro-segmentation

What to remember from this guide

Security and compliance conversations are less intimidating once you have a working model of what each layer is doing. IAM is the foundation — who gets in and what they can touch. Compliance frameworks like SOC2 are the language vendors use to prove they're handling your data responsibly. Privacy regulations like GDPR and HIPAA define your obligations to the people whose data you hold. The threat model is mostly about humans — phishing, credential reuse, social engineering — rather than exotic technical exploits. Vendor risk is a procurement discipline that most companies under-invest in until something goes wrong. And zero trust is the direction the field is heading — less about whether you're inside the building and more about who you are, on what device, and why you need access.

None of this requires deep technical expertise to engage with. It requires vocabulary and a willingness to ask the follow-up question — which, in security conversations, is usually the most valuable thing a business operator can contribute.

Related guides: Org & Roles — specifically §1 (CISO in the C-suite); Data Foundations — for the data-pipeline side of privacy compliance; Legal & Compliance — the contracts, IP, employment, and privacy-law side that pairs with the technical-controls side covered here

§7 Incident response — when something goes wrong Strategic

A security incident during which everyone is figuring out the process for the first time is a security incident that takes three times as long to resolve and produces twice as many additional problems. The purpose of an incident response program is to have the decisions that can be made in advance made in advance, so that the decisions that can only be made under pressure are fewer and faster.

The standard incident response lifecycle runs five phases: Detect → Contain → Eradicate → Recover → Post-mortem. Detection is where most of the leverage is. Many breaches go undetected for weeks or months — the 2020 SolarWinds compromise persisted for roughly nine months before discovery. Mean time to detect (MTTD) is the primary leading indicator of breach severity: a threat actor who's been in your environment for two hours has caused far less damage than one who's been there for sixty days. Investment in detection infrastructure — SIEM tools, anomaly detection, endpoint monitoring — is investment in shrinking MTTD.

Mean time to recover (MTTR) is the operational metric that tells you how effective your response is once a threat is identified. MTTR measures the full span from incident declaration to service restoration. Organizations that drill their incident response process regularly — through tabletop exercises and simulated breach scenarios — consistently achieve lower MTTR than those who only respond to real incidents. The improvement comes from muscle memory: team members who've run the playbook know where it says what, who to call when, and which decisions are pre-authorized rather than requiring escalation.

Communication during an incident is as operationally important as the technical response. Internal escalation paths need to be defined before an incident occurs: who declares an incident, who gets paged, who has authority to take systems offline, when does legal counsel get involved, when does the CEO. External communication requirements are legally defined: GDPR requires notification to the supervisory authority within 72 hours of discovering a personal data breach (and notification to affected individuals "without undue delay" if there's high risk). Most US states require notification to affected consumers within 30-60 days, with laws varying by state. Breach notification requirements are not optional, and missing a notification window adds regulatory liability on top of the incident itself.

Breach notification requirements GDPR 72 hrs to supervisory authority + individuals if high risk