If you're new to GRC and feeling lost in acronym soup, this glossary is your reference. It defines 50+ essential terms organized by category, each written in plain English with context showing where you'll encounter the term in real work. If a term isn't here, check the SANS Security Glossary, but you'll find the vast majority of what you need below.
Frameworks and Standards
SOC 2 (System and Organization Controls Type II)
An audit standard created by the AICPA that evaluates how a service organization manages data based on the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). This is the compliance standard you'll encounter most in US SaaS companies. A SOC 2 Type II report covers a 6‑to‑12‑month observation period rather than a single point‑in‑time assessment.
ISO/IEC 27001
The international standard for information security management systems (ISMS). Organizations build an ISMS following the standard's requirements and undergo certification audits by accredited bodies. The 2022 revision updated Annex A from 114 to 93 controls organized into four themes: Organizational, People, Physical, and Technological.
NIST CSF 2.0 (Cybersecurity Framework)
A voluntary framework from the National Institute of Standards and Technology that organizes cybersecurity activities into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Version 2.0 was published in February 2024, adding the Govern function as a new structural pillar. It’s widely adopted as a common language for communicating cyber risk across organizations.
NIST SP 800‑53
Security and privacy controls for federal information systems and organizations, published as Special Publication 800‑53. Revision 5 (released September 2020) contains over 1,000 controls organized into 20 families (Access Control, Audit and Accountability, Risk Assessment, etc.). Required for federal systems, it’s also a reference baseline in the private sector.
PCI DSS (Payment Card Industry Data Security Standard)
Security standard for organizations that handle credit‑card information. Managed by the PCI Security Standards Council. Version 4.0 was published March 2022 with a transition deadline of March 31 2025. It defines 12 core requirements including network security, data protection, access management, vulnerability management, and monitoring.
HIPAA (Health Insurance Portability and Accountability Act)
US federal law enacted in 1996 that establishes privacy and security standards for protected health information (PHI). The Security Rule (45 CFR Part 164 Subparts A and C) specifies administrative, physical, and technical safeguards. The Privacy Rule governs use and disclosure of PHI by covered entities and business associates.
GDPR (General Data Protection Regulation)
EU regulation (EU) 2016/679 that took effect May 25 2018, governing the processing of personal data of individuals in the European Economic Area. Key requirements include lawfulness of processing, data‑subject rights (access, erasure, portability), data‑protection impact assessments, breach notification within 72 hours, and penalties up to 4 % of global annual revenue or €20 million.
COBIT (Control Objectives for Information and Related Technologies)
A framework for governance and management of enterprise IT, published by ISACA. COBIT 2019 updated the framework to align with modern IT environments. It’s less commonly seen as a standalone compliance requirement but useful for understanding the relationship between governance, risk, and IT operations.
CIS Controls (Center for Internet Security Critical Security Controls)
A prioritized set of 18 cybersecurity safeguards published by CIS (formerly SANS Institute). Version 8 was released in 2021. Controls are organized into Implementation Groups: IG1 (basic cyber hygiene for all organizations), IG2 (for organizations handling sensitive data), and IG3 (enterprise‑grade security). Frequently used as a practical baseline for startups and SMBs.
Risk Terminology
Inherent Risk
The level of risk that exists before any controls are applied. If you operate an internet‑facing database storing customer credit‑card numbers, the inherent risk is high regardless of what security measures you plan to implement later.
Residual Risk
The level of risk that remains after controls have been applied. If you encrypt the database, implement MFA, and restrict network access, you’ve reduced inherent risk—but the residual risk depends on how well those controls are designed, implemented, and maintained.
Risk Appetite
The amount and type of risk an organization is willing to accept in pursuit of its objectives. Usually expressed as a statement approved by the board or senior management. Example: “Our organization accepts low risk for customer‑data security but moderate risk for experimental internal tooling.”
Risk Tolerance
The acceptable variation from the stated risk appetite. Where risk appetite is a strategic directional statement, risk tolerance is the measurable boundary. Example: “Systems handling customer PII must have all critical patches applied within 72 hours.” The 72‑hour threshold is the tolerance.
Risk Assessment
The systematic process of identifying, analyzing, and evaluating risk against an organization’s risk appetite and tolerance. Includes asset identification, threat and vulnerability analysis, likelihood and impact determination, and risk scoring. Can be qualitative (using descriptive scales) or quantitative (using numerical probability and financial impact).
Risk Register
A structured document or database that catalogs identified risks with attributes including risk ID, description, owner, likelihood, impact, risk score, existing controls, recommended treatment, treatment decision, and target date. It’s the central artifact for tracking organizational risk over time.
Risk Treatment
The response to an identified risk. Four options exist: mitigate (implement controls to reduce risk), accept (acknowledge the risk and take no action), transfer (shift risk to another party, typically through insurance or contracts), or avoid (eliminate the activity that creates the risk).
FAIR (Factor Analysis of Information Risk)
A quantitative risk analysis methodology that decomposes risk into measurable components: loss event frequency, threat event frequency, vulnerability, contact frequency, probable loss magnitude, and secondary loss. It provides a structured way to express risk in financial terms rather than subjective “high/medium/low” ratings.
Third‑Party Risk (TPR) / Vendor Risk
Risk introduced to an organization through its relationships with external entities including vendors, suppliers, contractors, partners, and cloud service providers. A vendor with access to your systems or data carries risk equivalent to internal exposure, requiring assessment, monitoring, and contractual controls.
Risk Owner
The individual accountable for managing a specific risk within the organization. Typically a senior leader with authority to make decisions about the risk, allocate resources for treatment, and report status to governance bodies. Risk owners are not the same as control owners (who manage the controls that mitigate risk).
Compliance and Audit Terms
Control
A measure designed to reduce risk to an acceptable level. Controls are categorized as administrative (policies, procedures, training), technical (firewalls, encryption, access controls), or physical (locks, cameras, badge systems). Each control should have a defined purpose, owner, and evidence of operation.
Evidence
Documentation or artifacts that demonstrate a control is operating as designed. Examples: policy documents with version history and approval signatures, screenshots of security configurations, access logs, training completion records, vulnerability‑scan reports, penetration‑test results. Auditors collect evidence to verify control effectiveness.
Audit
An independent examination of an organization’s controls, processes, and compliance with applicable requirements. Internal audits are conducted by employees within the organization. External audits are performed by independent third parties (audit firms). SOC 2 audits are performed by CPA firms accredited by the AICPA.
Attestation
A formal statement by a qualified party (typically a CPA firm) confirming that it has examined management’s assertion about its controls and expressing an opinion on the fairness of that assertion. A SOC 2 attestation opinion can be unqualified (clean), qualified (exceptions noted), adverse (material weaknesses), or disclaimer (insufficient evidence).
Certification
Formal recognition by an accredited body that an organization meets the requirements of a specific standard. ISO 27001 certification is granted after a two‑stage audit by an accredited certification body. PCI DSS compliance is validated by a Qualified Security Assessor (QSA). HIPAA does not offer formal certification—organizations are either compliant or not.
Audit Finding
A deficiency or gap identified during an audit that indicates a control is missing, inadequately designed, or not operating effectively. Findings are typically rated by severity (critical, high, medium, low) and assigned to an owner with a remediation deadline.
Remediation
The process of correcting an identified deficiency or audit finding. Remediation may involve implementing a new control, redesigning an existing control, updating documentation, or changing procedures. Remediation plans should include the corrective action, responsible party, target completion date, and validation criteria.
Gap Assessment
An evaluation comparing an organization’s current controls against a target framework to identify what is missing or inadequate. This is typically the first step in a compliance program—before you build controls, you need to know where you stand.
Scope
The boundaries of an audit or assessment. Defines which systems, processes, locations, and data are included. A poorly defined scope leads to incomplete assessments or unexpected findings. SOC 2 scope definitions include the services covered, data centers used, and systems relevant to the Trust Services Criteria.
Compliance
Conforming to laws, regulations, standards, contractual obligations, and internal policies. Compliance can be mandatory (required by law like HIPAA or PCI DSS for card processing) or voluntary (adopted for competitive advantage like SOC 2 or ISO 27001).
Security Fundamentals
CIA Triad
The three foundational principles of information security: Confidentiality (ensuring information is accessible only to authorized parties), Integrity (ensuring information is accurate and has not been improperly modified), and Availability (ensuring information and systems are accessible when needed by authorized users). Every security control maps back to at least one of these principles.
Zero Trust
A security model that assumes no user, device, or network is inherently trustworthy. Every access request must be verified, authenticated, and authorized before granting access, regardless of where the request originates (internal network or external). NIST SP 800‑207, published August 2020, formalized the zero‑trust architecture concepts.
MFA (Multi‑Factor Authentication)
An authentication method requiring two or more independent verification factors: something you know (password, PIN), something you have (smartphone, hardware token), or something you are (fingerprint, facial recognition). MFA is a baseline control required by virtually every modern compliance framework.
Encryption
The process of converting readable data (plaintext) into an unreadable format (ciphertext) using an algorithm and a key. Encryption protects data at rest, in transit, and sometimes in use, ensuring that even if an unauthorized party intercepts the data, they cannot decipher its contents without the appropriate key.
Key Takeaways
- Start with a Gap Assessment – Before chasing certifications, map your current controls against the framework you need (e.g., ISO 27001, SOC 2). The gaps you uncover become your roadmap.
- Prioritize Risks by Business Impact – Use inherent and residual risk concepts to focus on what truly matters to your customers and board. High‑impact risks get the most resources.
- Document Evidence Early – Treat evidence collection as a continuous activity, not a post‑audit scramble. Simple things like version‑controlled policies and automated log exports save weeks of work.
- Embed a Risk Owner for Every Critical Asset – Assign clear accountability; a risk owner drives remediation and reports status to governance bodies.
- Adopt Zero Trust Fundamentals – Even if you’re not ready for a full Zero Trust architecture, start with MFA, least‑privilege access, and micro‑segmentation to raise your security baseline quickly.
Conclusion
A solid grasp of GRC terminology is more than academic—it’s the foundation for building a compliance program that actually works. By familiarizing yourself with the frameworks, risk concepts, audit language, and security fundamentals outlined here, you can speak the same language as auditors, regulators, and executives. That shared vocabulary makes it easier to identify gaps, prioritize remediation, and demonstrate progress to stakeholders.
Use this glossary as a living reference. When you encounter a new acronym or phrase, look it up, note how it fits into your organization’s risk picture, and update your internal docs accordingly. With the right terms under your belt and a clear action plan, navigating the GRC landscape becomes far less intimidating—and far more effective.