The GRC industry has a language problem. Terms like "compliant," "secure," "policy," and "risk" are used so loosely, and so incorrectly, that they create genuine legal exposure, failed audits, and programs built on a foundation of misunderstanding. These are the worst offenders.
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
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.
Each entry shows the wrong usage, the correct usage, and the real-world consequence of getting it wrong.
Used as a permanent state, as in "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.
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.
"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.
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.
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.
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.
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.
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: The potential for loss or harm resulting from a threat exploiting a vulnerability. Risk = Likelihood x Impact. "Risk that ransomware actors exploit the unpatched Exchange server, encrypting 30TB of patient data, with estimated impact of $4.2M."
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.
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.
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.
"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, as in "we followed best practices," as if that phrase constitutes a legal defense. It does not.
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.
Security and privacy are routinely treated as synonymous. Encrypting data protects its confidentiality and integrity, which is a security control. But privacy is about lawful processing, purpose limitation, individual rights, and data subject consent. These are legal obligations that encryption does not address at all.
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, such as 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.
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.
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.
A practical substitution guide for the most common word crimes in GRC communications, documentation, and executive reporting.
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. It is not a permanent state.
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.
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.
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.
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.
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.
%20(white).png)
.png)