Word Crimes

Why Language Matters in GRC

Imprecise Language Creates Precise Liability

When an executive tells a board “we are compliant,” that statement has different legal weight depending on whether it means “we have checked every mandatory requirement and can evidence it” or “we did our best.” Courts and regulators do not grade on effort.

When a vendor contract says “reasonable security,” what that phrase means in litigation is determined by what controls the industry considers standard — not what the vendor thought was good enough. When a policy document is labeled “policy” but written as a procedure, auditors flag it. When “risk” and “vulnerability” are used interchangeably, the risk register becomes meaningless.

These are not theoretical concerns. Enforcement actions, class action lawsuits, and failed third-party audits regularly cite imprecise or misleading language in compliance documentation as a contributing factor in findings.

The SCF Approach to Terminology

Every term used in the SCF CCF™ — from “policy” to “risk” to “compliant” — is used with its precise regulatory and legal meaning. The SCF documentation, assessment methodology (CDPAS), and control catalog use consistent terminology that aligns with how courts, regulators, and auditors actually interpret these words.

The Word Crimes

The GRC Industry’s Most Harmful Terminology Mistakes

Each entry shows the wrong usage, the correct usage, and the real-world consequence of getting it wrong.

Guilty

"We Are Compliant"

The single most dangerous sentence in GRC

✗ What people mean

"We have a program in place and we think we generally meet the requirements."

Used as a permanent state — "we are compliant" — as if compliance is achieved once and maintained passively. Often stated without evidence, without a completed assessment, and without specific reference to which obligations are being met.

✓ What it actually means

"We have assessed all applicable requirements, we have evidence of implementation for each, and we have no open material gaps — as of the date of our last assessment."

Compliance is point-in-time, evidence-based, and obligation-specific. You are not "compliant with HIPAA" — you are compliant with the HIPAA Security Rule’s 45 CFR Part 164 requirements as of your last documented risk assessment. Compliance decays as systems change and is re-established through assessment.

Real Consequence: Executives who tell boards or investors "we are compliant" and then suffer a breach face securities fraud exposure if the claim was not evidence-backed. The FTC has pursued enforcement against companies whose public compliance claims were not substantiated. In litigation, "we thought we were compliant" is not a defense.

Guilty

"We Are Secure"

An absolute claim no organization can make or defend

✗ What people mean

"We have security controls in place and haven’t been breached."

"Not yet breached" is routinely conflated with "secure." Organizations point to their firewall, their endpoint agent, their SOC 2 report, or their penetration test from 18 months ago as proof of security. None of these are proof of security — they are evidence of specific controls at a point in time.

✓ What to say instead

"We maintain a risk-based cybersecurity program targeting SCR-CMM Level 3 maturity across our prioritized control domains. Our current assessed risk posture shows X open findings rated critical or high."

Security is a continuous, risk-managed state — not a binary. The honest representation is the current state of the risk register, the maturity level of the control program, and the open remediation items. The SCR-CMM provides a defensible, quantified way to describe security posture without making absolute claims.

Real Consequence: Marketing claims of "secure" or "bank-grade security" have been cited in FTC actions and class action lawsuits as deceptive trade practices following breaches. Vendor contracts that warrant security without qualification create unlimited contractual liability. Never warrant security — warrant a specific, documented control program.

Misused

Policy / Procedure / Standard / Guideline

Four distinct document types used interchangeably — and auditors know the difference

✗ The common mistake

"Here is our Password Policy" [document contains step-by-step instructions for setting a password and minimum length requirements — which are a procedure and a standard, not a policy].

Organizations mislabel standards as policies, procedures as guidelines, and guidelines as standards. When an auditor asks for your "information security policy," they expect a management-approved statement of intent and direction — not a 47-page technical how-to document.

✓ The correct hierarchy

Policy: Management-approved statement of intent, direction, and principle. "The organization shall protect information assets commensurate with their classification." Mandatory. Brief. Board-accessible.

Standard: Specific, measurable requirement. "Passwords must be minimum 12 characters with complexity." Mandatory. Quantitative. Technology-specific.

Procedure: Step-by-step instructions for performing a task. "To reset a password: 1. Navigate to... 2. Click..." Operational. Role-specific.

Guideline: Recommended but non-mandatory advice. "Users should consider using a password manager." Advisory. Discretionary.

Real Consequence: Auditors and regulators have specific expectations for each document type. Presenting a procedure in response to a policy request is a finding. More importantly, when "everything is a policy," nothing enforces accountability — because policies without standards have no measurable compliance threshold.

Misused

Risk / Vulnerability / Threat

Three distinct concepts that combine to create risk — not synonyms for it

✗ What people say

"We identified a risk in the vulnerability scan." / "The threat is that we don’t have MFA." / "Our biggest risk is ransomware."

All three terms are used interchangeably in most organizations. A vulnerability scan identifies vulnerabilities — not risks. MFA absence is a control gap or vulnerability — not a threat. Ransomware is a threat actor category — risk is the product of that threat exploiting a vulnerability to cause impact.

✓ Precise definitions

Threat: A potential event or actor that could cause harm. "Ransomware-as-a-service operators targeting healthcare organizations."

Vulnerability: A weakness that a threat could exploit. "Unpatched Exchange server reachable from the internet."

Risk: Potential for loss resulting from a threat exploiting a vulnerability. Risk = Likelihood × Impact. "Risk that ransomware actors exploit the unpatched Exchange server, encrypting 30TB of patient data, estimated impact of $4.2M."

Control: A measure that reduces the likelihood or impact of a risk materializing.

Real Consequence: Risk registers that list vulnerabilities instead of risks cannot be prioritized by business impact. Boards receiving "vulnerability reports" labeled as "risk reports" cannot make informed risk acceptance decisions. The SCR-RMM requires precise use of these terms — risk treatment decisions must be made at the risk level, not the vulnerability level.

Conflated

Audit / Assessment / Review

Different independence requirements, different legal weight, different outputs

✗ How they're confused

"We had an audit done" [conducted by an internal team member] / "Our annual security review satisfies our audit requirement" / "The vendor provided an audit report" [it was a self-assessment questionnaire].

Organizations routinely represent internal assessments as audits to regulators, boards, and customers. Some regulations explicitly require independent audits — presenting a self-assessment as an audit to a regulator is a compliance failure and potentially a misrepresentation.

✓ Precise distinctions

Audit: An independent, formal examination by a qualified third party producing an opinion or attestation. Has defined independence requirements. Legally significant. Examples: SOC 2 Type II, HIPAA independent audit, CMMC C3PAO assessment.

Assessment: A structured evaluation that may be conducted internally or by a qualified third party. Produces findings and recommendations. Not an opinion or attestation. Examples: CDPAS self-assessment (Type 1), CDPAS third-party assessment (Type 2).

Review: An informal evaluation — typically internal, less structured, advisory in nature. Does not satisfy audit or assessment requirements under most regulatory frameworks.

Real Consequence: GLBA requires an annual "risk assessment." NY DFS requires an annual "penetration test" and "audit." HIPAA requires periodic "security risk analysis." Each of these has specific requirements that a generic "review" does not satisfy. Regulators have taken enforcement action against organizations that conducted inadequate assessments and labeled them as required audits.

Misused

"Best Practices"

A phrase used to validate anything and mean nothing

✗ How it's weaponized

"We follow industry best practices." / "This configuration aligns with best practices." / "Best practices require you to implement X."

"Best practices" is invoked constantly to lend authority to recommendations that may be highly subjective, vendor-specific, outdated, or inapplicable to the organization’s context. It is also used defensively — "we followed best practices" — as if that phrase constitutes a legal defense. It does not.

✓ What to say instead

"NIST SP 800-63B Section 5.1.1 recommends a minimum password length of 8 characters for memorized secrets. The SCF control IAC-XX requires [specific requirement]. Our implementation aligns with NIST SP 800-63B and satisfies SCF IAC-XX."

Cite the specific authoritative source. "Best practices" means nothing in litigation or a regulatory exam. "NIST SP 800-63B, Section 5.1.1" means something. The SCF STRM methodology exists precisely to provide this specificity — every SCF control traces to the authoritative source that requires or recommends it.

Real Consequence: In litigation, expert witnesses on both sides invoke "best practices" to support contradictory positions. Courts have increasingly demanded specific citations. Organizations whose security programs reference "best practices" without named standards cannot demonstrate what standard they were actually applying — which undermines the "reasonable security" defense in breach litigation.

Conflated

Privacy / Security / Confidentiality

Three distinct obligations with completely different legal sources

✗ How they're conflated

"We protect privacy by encrypting personal data." / "Our security program covers our privacy obligations." / "We keep data confidential, so we’re compliant with GDPR."

Security and privacy are routinely treated as synonymous. Encrypting data protects its confidentiality and integrity — this is a security control. But privacy is about lawful processing, purpose limitation, individual rights, and data subject consent — legal obligations that encryption does not address at all.

✓ Distinct meanings

Security: The set of technical and organizational controls that protect the confidentiality, integrity, and availability of information systems and data. A security program can be excellent while still violating every privacy law.

Privacy: The right of individuals to control how their personal data is collected, used, shared, and retained. A privacy program addresses legal bases, consent, individual rights, and purpose limitation — none of which are security controls.

Confidentiality: One of the three pillars of security (CIA triad — Confidentiality, Integrity, Availability). Protecting data from unauthorized disclosure. A security property, not a privacy principle.

Real Consequence: Organizations with excellent security programs have received massive GDPR fines not for security failures but for privacy violations — processing data without valid legal basis, retaining data longer than permitted, or failing to fulfill data subject access requests. Security and privacy require separate program components, as reflected in the SCF's separate DCH and PRI domains.

Misused

"Reasonable Security"

A legal standard, not a subjective opinion

✗ How it's misunderstood

"We implement reasonable security" [meaning: we do what our budget allows and what we think is sensible].

Many US state laws, the FTC Act, and common law negligence claims use "reasonable security" as the compliance standard. Organizations assume this is a flexible, subjective standard that accommodates their constraints. Regulators and courts do not agree.

✓ What courts and regulators mean

"Reasonable security means implementing controls that are appropriate to the nature, size, and complexity of the organization and the sensitivity of the data — measured against recognized industry standards."

The FTC and state AGs have consistently measured "reasonable security" against NIST CSF, NIST SP 800-53, and CIS Controls. The SCF CCF™ — as the most comprehensive metaframework mapping all recognized standards — provides the most defensible foundation for demonstrating "reasonable security" because it documents precisely how controls satisfy each applicable standard.

Real Consequence: The FTC has pursued enforcement against companies for "unfair or deceptive" security practices under Section 5 of the FTC Act — which requires "reasonable security." In every major case, the question was whether the organization's controls met the standard a reasonable company in their position would implement, measured against published frameworks. "We thought it was reasonable" is not a defense; "we implemented controls X, Y, Z per NIST SP 800-53 Moderate baseline" is.

Quick Reference

Say This, Not That

A practical substitution guide for the most common word crimes in GRC communications, documentation, and executive reporting.

Instead of "We are compliant"

Say: "As of our [date] CDPAS assessment, we have no open critical or high findings against our applicable MCRs. Our next scheduled assessment is [date]."

Compliance is evidence-based, point-in-time, and obligation-specific — not a permanent state.

Instead of "We are secure"

Say: "Our current SCR-CMM score is Level [X] across our prioritized control domains. Our open risk register shows [N] critical and [N] high risk items currently in remediation."

Security is a quantified, dynamic posture — not a binary state.

Instead of "Best practices"

Say: "[Specific control], per [specific standard, section, version]." e.g., "MFA for all remote access, per NIST SP 800-63B and SCF IAC-09."

Cite the authoritative source. "Best practices" is not a defense in litigation or a regulatory exam.

Instead of mixing Policy/Procedure/Standard

Use a tiered documentation structure: Policy (intent) → Standard (requirement) → Procedure (steps) → Guideline (recommendation). Label each correctly.

Auditors expect each document type to match its label and serve its purpose.

Instead of "Risk" when you mean "Vulnerability"

Call vulnerabilities vulnerabilities. Reserve "risk" for: Threat + Vulnerability + Likelihood + Impact — a quantified statement of potential loss, not a finding from a scan.

Risk registers must contain risks — not vulnerability inventory.

Instead of "Our security covers privacy"

Say: "Our security program addresses CIA of personal data. Our privacy program addresses lawful basis, individual rights, data minimization, and cross-border transfers." These are separate programs.

Security and privacy are complementary but legally distinct obligations.

Word Crimes

Imprecise Language Creates Precise Liability

The GRC Industry’s Most Harmful Terminology Mistakes

Say This, Not That

Instead of "We are compliant"

Instead of "We are secure"

Instead of "Best practices"

Instead of mixing Policy/Procedure/Standard

Instead of "Risk" when you mean "Vulnerability"

Instead of "Our security covers privacy"

Build a GRC Program on Precise Language