GRC and Cyber Compliance Glossary: Plain Definitions of Risk, Control and Audit Terms

Governance, risk and compliance teams lose time to vocabulary: auditors, risk managers, engineers and executives use the same words for different things, and frameworks define them differently again. This glossary gives short, precise definitions of the terms practitioners meet when running a cyber risk register, building a control framework, preparing for an ISO/IEC 27001 certification or a SOC 2 examination, testing controls and reporting to a board. Where an authoritative source defines a term, the entry follows it and names it: NIST glossary entries, ISO 31000, The Open Group's Open FAIR standards and the AICPA's SOC suite. Where frameworks disagree, the entry says so. It is written for GRC analysts, internal and external auditors, control owners and security leaders. Identity terms such as access certification are covered in more depth in the NHI and IAM Glossary, and incident terms in the Incident Response and DFIR Glossary.

A

Access review

A periodic check, by a manager or resource owner, that each account's access is still needed and appropriate. For auditors it is one of the most frequently tested controls, and the evidence they ask for is the review population, the decisions and proof that revocations were actually carried out. See the Access Reviews Guide.

Assessment procedure (examine, interview, test)

The three methods NIST SP 800-53A uses to assess a control: examine documents and configurations, interview people responsible, and test the mechanism in operation. Stronger assurance comes from testing than from examination alone, so mature programmes record which method produced each piece of evidence.

Assertion (management assertion)

A written statement by management, included in attestation reports such as SOC 1 and SOC 2, that the system description is fairly presented and the controls were suitably designed (and, for a Type 2 report, operated effectively). The auditor's opinion is on management's assertion, which is why the scope wording matters. See the How to Read a SOC 2 Report Guide.

Attestation

A formal statement that something is true. In audit it means an engagement in which an independent practitioner reports on a subject matter or an assertion about it, such as a SOC 2 examination. In internal GRC it often means a control owner's or employee's signed confirmation, such as policy acknowledgement, which is weaker evidence than independent testing.

Audit

A systematic, independent and documented process for obtaining evidence and evaluating it objectively to decide how far criteria are met. Internal audits serve the organisation; external audits are performed by an independent body, for example for ISO/IEC 27001 certification. See Internal Audit vs External Audit.

Audit evidence

The records, statements and observations an auditor uses to reach a conclusion: system reports, configuration exports, tickets, logs, screenshots, interview notes and re-performance results. Good evidence is relevant, reliable (system-generated beats manually compiled), complete for the period and traceable to its source. See the Audit Evidence and Continuous Controls Monitoring Guide.

Audit finding

An auditor's documented result where evidence shows a criterion is not met. Findings are usually graded (for example major or minor nonconformity in ISO certification, or exception and deficiency in attestation work) and carry an expectation of corrective action with an owner and date.

Audit period

The span of time an audit covers. A point-in-time engagement looks at design on one date; a period engagement, such as a SOC 2 Type 2 report, looks at operation over a window, commonly several months to a year. Controls that changed mid-period need evidence for both versions. See Continuous Compliance vs Point-in-Time Audits.

Audit trail

A chronological record of system activity that lets a reviewer reconstruct who did what, when and with what result. Auditors check that audit trails exist, are protected from alteration and are retained for the required period (NIST SP 800-53 AU-9 and AU-11).

B to C

Board risk reporting

The regular presentation of the organisation's top cyber risks, trends against appetite, key risk indicators and major remediation decisions to the board or its risk committee. Good reporting states the decision the board is being asked to make; poor reporting is a heat map without context.

Business impact analysis (BIA)

An analysis of the effect of disruption to business processes over time, used to set recovery time and recovery point objectives and to rank which systems need protection first. A BIA measures consequence; a risk assessment adds likelihood. See Business Impact Analysis vs Cyber Risk Assessment.

Certification body

An independent organisation that audits a management system against a standard such as ISO/IEC 27001 and issues a certificate. Certification bodies are themselves accredited by a national accreditation body, which is why buyers check the accreditation mark on a certificate. See the ISO 27001 Certification Body Selection buyer's guide.

Certification cycle

The ISO management system cycle: an initial certification audit in two stages (documentation and readiness, then implementation), surveillance audits in the following years, and a recertification audit before the certificate expires, typically on a three-year cycle. See the ISO 27001 Certification Guide.

Common control

NIST SP 800-53 Rev. 5 defines a common control as a security or privacy control that is inherited by multiple information systems or programs. Examples are physical security of a data centre or an enterprise identity provider: the provider documents and tests the control once, and each system inherits it. See the Common Control Framework Template.

Common control framework (unified control framework)

A single internal set of controls mapped to several external frameworks and laws, so one control and one piece of evidence can satisfy ISO/IEC 27001, SOC 2, PCI DSS and NIST requirements at once. It is the main defence against duplicated audit work.

Compensating control

NIST defines it as a management, operational or technical control used in place of a recommended baseline control, providing similar or comparable protection. In practice it must address the same risk as the original requirement, be documented, approved and reviewed, and is never just "we accept the risk". See the Hardening Exceptions and Compensating Controls Template.

Compliance

Meeting obligations: laws, regulations, contracts, standards the organisation has committed to, and its own policies. Compliance is necessary but not the same as security; a compliant organisation can still carry high risk. See Compliance vs Security.

Compliance obligation

A single requirement the organisation must meet, traced to its source (statute article, regulator rule, contract clause) and mapped to the controls that satisfy it. Obligations are kept in an obligations register so that a change in law can be traced to affected controls. See the Compliance Obligations Register Template.

Control

A measure that modifies risk: a policy, process, device, practice or technical setting. Controls are described by type (preventive, detective, corrective), by nature (manual, automated, IT-dependent manual) and by frequency, and each needs an owner and a testable objective.

Control deficiency

A shortcoming in a control's design (it would not meet its objective even if operated as designed) or operation (it is designed well but was not performed as intended). Deficiencies are rated, in financial reporting contexts as deficiency, significant deficiency or material weakness. See Audit Exception vs Control Deficiency.

Control objective

The outcome a control is meant to achieve, written so it can be tested: for example "only authorised changes are deployed to production". Writing the objective first stops teams from testing activity instead of outcome.

Control owner

The named person accountable for a control being designed, operated and evidenced. Ownership by a team or a tool, rather than a person, is a common reason controls lapse without anyone noticing.

Control testing

Checking whether a control is designed effectively (test of design) and whether it operated as designed over a period (test of operating effectiveness). Methods include inquiry, observation, inspection of evidence and re-performance; inquiry alone is not sufficient evidence of operation.

Corrective action

Action to remove the cause of a nonconformity and prevent it recurring, as required by ISO management system standards. It differs from a correction, which only fixes the immediate instance; auditors look for root cause analysis and a check that the action worked.

Corrective control

A control that limits damage and restores normal operation after an event, such as backup restoration, account disablement or patch deployment after a vulnerability is found.

D to G

Defence in depth

Layering independent controls so that the failure of one does not expose the asset. In GRC it shows up when assessing residual risk: two weak but independent controls can reduce risk more than one strong control with a single point of failure.

Detective control

A control that identifies an event after it has occurred or while it is happening, such as log monitoring, reconciliations, access reviews and integrity checks. Detective controls only reduce risk if someone acts on what they find, so auditors test the follow-up, not just the alert.

Enterprise risk management (ERM)

The organisation-wide process for identifying, assessing and managing all types of risk (financial, operational, strategic, compliance and cyber) against a common appetite. Cyber risk registers should feed ERM using its scales, so cyber risks can be compared with other business risks. See the ISO 31000 Risk Management Guide.

Exception (audit)

An instance found during testing where a control did not operate as described, for example one access request out of 25 sampled with no approval. An exception is a fact found in a sample; whether it amounts to a deficiency depends on its cause and significance.

FAIR (Factor Analysis of Information Risk)

A model for analysing information risk in financial terms, standardised by The Open Group as Open FAIR. Open FAIR is defined by two standards: O-RT, the Risk Taxonomy, which breaks risk into loss event frequency and loss magnitude and their factors, and O-RA, the Risk Analysis standard, which describes how to perform the analysis. See the FAIR Model and Open FAIR Standard Guide.

Framework

A structured set of practices or controls, usually voluntary, such as NIST CSF 2.0, ISO/IEC 27001 Annex A, CIS Controls or COBIT. A regulation is binding law; a framework becomes binding only when a law, contract or certification requires it. See Control Frameworks vs Regulations.

Gap assessment

A comparison of current practice against a target standard or law, producing a list of gaps and a remediation plan. It is diagnostic and private; it is not an audit and does not produce an opinion. See Gap Assessment vs Readiness Assessment vs Audit.

Governance

The system by which an organisation is directed and held to account: who sets direction, who decides, who is accountable and how performance is monitored. In cyber security it covers strategy, roles, policy, risk appetite and oversight. NIST CSF 2.0 added Govern (GV) as a sixth function for this reason. See the NIST CSF 2.0 Govern Function Guide.

GRC (governance, risk and compliance)

The combined discipline of directing the organisation, managing its risks and meeting its obligations, and the processes and tools that connect them. GRC is also used for the team that runs the risk register, control framework, policy set and audits. See the Audit, Assurance and Compliance Guide.

GRC platform

Software that holds the risk register, control library, framework mappings, policies, evidence requests, issues and reporting in one place, often with integrations that collect evidence automatically. See the GRC Platform Buyer's Guide and the GRC Platform RFP Template.

H to K

Heat map

A grid plotting risks by likelihood and impact, usually on a 5 by 5 scale, coloured to show severity. Heat maps are easy to read but hide uncertainty and can mislead when ordinal scores are multiplied as though they were numbers; quantitative methods such as FAIR address that weakness.

Inherent risk

The level of risk before taking account of controls, or with controls assumed absent. It is used to decide how much control effort a risk deserves and to show what would happen if key controls failed. See Inherent Risk vs Residual Risk.

Information security management system (ISMS)

The management system that ISO/IEC 27001 requires: the policies, roles, risk assessment and treatment process, controls, monitoring, internal audit and management review used to manage information security as a continuous cycle. The certificate is for the ISMS, within a stated scope, not for a product.

Internal audit

An independent, objective assurance and advisory function inside the organisation that reports to the board or audit committee. In the IIA's Three Lines Model it provides third line assurance. ISO/IEC 27001 also requires planned internal audits of the ISMS. See the Internal Audit for Cybersecurity Guide.

Internal control

The processes put in place by management to give reasonable assurance that objectives for operations, reporting and compliance are achieved. The COSO Internal Control Integrated Framework is the most widely used reference for this definition. See COBIT vs COSO.

IT general controls (ITGCs)

Controls over the IT environment that support the reliability of applications and data, usually grouped as access to programs and data, program change, program development and computer operations. They are central to SOX and SOC 1 work. See SOX ITGCs vs SOC 1.

Key risk indicator (KRI)

A metric that signals rising exposure before a loss happens, with thresholds tied to risk appetite, such as the percentage of critical vulnerabilities past their remediation deadline. A KPI measures how well a process performs; a KRI measures how much risk is building up. See the Key Risk Indicators for Cyber Risk Guide and KRI vs KPI in Cyber Security.

L to O

Least privilege

The principle that each user, process and system has only the access it needs for its function and no more. Auditors test it through access reviews, privileged account inventories and role design, including for service accounts and other non-human identities.

Likelihood

The chance of something happening, expressed qualitatively (rare to almost certain), as a frequency (once in ten years) or as a probability. Defining the scale in writing, with examples, is what makes two assessors give the same score.

Management review

A required ISO/IEC 27001 activity in which top management reviews the ISMS at planned intervals: audit results, risk status, performance metrics, nonconformities and changes. Minutes of the review are a standard piece of certification evidence. See ISMS Internal Audit and Management Review.

Material weakness

In financial reporting audits, a deficiency, or combination of deficiencies, in internal control such that there is a reasonable possibility that a material misstatement will not be prevented or detected in time. It is the most severe deficiency rating and is publicly disclosed by listed companies in some jurisdictions.

Materiality

The threshold above which a matter is significant enough to influence decisions by those relying on the information, such as investors or regulators. In cyber it matters for incident disclosure rules and for deciding which deficiencies to report upwards.

Nonconformity

Non-fulfilment of a requirement, in ISO management system language. Certification bodies grade nonconformities as major (a requirement is not met, or the system has broken down) or minor (an isolated lapse); a major nonconformity normally has to be closed before certification is granted or kept.

Opinion (audit opinion)

The auditor's formal conclusion in an attestation report. An unqualified opinion means the criteria were met in all material respects; a qualified opinion means they were met except for stated matters; an adverse opinion means they were not met. Readers of a SOC report should read the exceptions section, not just the opinion.

P to R

Plan of action and milestones (POA&M)

NIST SP 800-53 Rev. 5 describes a POA&M as a document that identifies tasks that need to be accomplished, with the resources required, milestones and scheduled completion dates. It is the standard record for tracking control weaknesses in US federal programmes such as FedRAMP. See the NIST Risk Management Framework (SP 800-37) Guide.

Policy

A statement of management intent and rules, approved at senior level, that tells people what must be done and why. Policies are short and stable; standards set specific mandatory values; procedures describe how; guidelines advise. See the Information Security Policy Template.

Policy exception

A formally approved, time-limited departure from a policy or standard, recorded with the business reason, the risk, any compensating controls, an accountable approver and an expiry date. An exception without an expiry date is an undocumented policy change. See the Security Exceptions and Risk Acceptance Guide.

Preventive control

A control that stops an adverse event from happening, such as multi-factor authentication, segregation of duties, change approval or input validation. Preventive controls are preferred where practical because they do not depend on someone reacting in time.

Readiness assessment

A rehearsal before a formal audit, often performed by a third party, that tests whether controls and evidence will satisfy the auditor. Unlike a gap assessment it assumes controls are largely in place and checks evidence quality. See the ISO 27001 Certification Readiness Checklist.

Re-performance

A test method in which the auditor independently executes a control, such as recalculating a reconciliation or re-running a user access report, to confirm it produces the claimed result. It gives stronger evidence than inspection.

Residual risk

The risk remaining after controls and other treatment have been applied. Residual risk above appetite needs further treatment or formal acceptance by someone with the authority to accept it.

Risk

ISO 31000 defines risk as the effect of uncertainty on objectives. In cyber practice a risk statement names the asset or objective, the threat or event, the vulnerability or condition, and the consequence, so it can be owned and measured. ISO 31000:2018 provides principles, a framework and a process for managing risk; it is guidance and is not certifiable.

Risk acceptance

An informed decision by an authorised person to take a risk without further treatment. Acceptance should be recorded with the residual rating, the reason, the approver's authority level and a review date. See the Security Exceptions and Risk Acceptance Guide.

Risk appetite

NIST, drawing on COSO, defines risk appetite as the types and amount of risk, on a broad level, an organisation is willing to accept in its pursuit of value. It is set by the board, expressed in qualitative statements and quantitative limits, and used to judge whether residual risks need more treatment. See the Cyber Risk Appetite Statement Template.

Risk assessment

The overall process of risk identification, risk analysis and risk evaluation, in ISO 31000 terms. Identification finds and describes risks, analysis works out their nature and level, and evaluation compares the results against criteria to decide what needs treatment.

Risk owner

The person with the accountability and authority to manage a risk, usually a business leader rather than the security team. The risk owner decides on treatment and accepts residual risk; control owners operate the controls that treat it.

Risk register

The record of identified risks with their description, owner, inherent and residual ratings, linked controls, treatment decisions, actions and review dates. A register is only useful if it drives decisions and is reviewed on a schedule. See the Risk Register Template.

Risk scenario

A concrete description of how a loss could happen: who or what acts, against which asset, by what means, with what consequence. Scenarios are the unit of analysis in quantitative methods and make qualitative scoring more consistent. See the Cyber Risk Quantification Guide.

Risk tolerance

Definitions vary. NISTIR 8286, drawing on ISO Guide 73, describes it as the organisation's or stakeholder's readiness to bear residual risk after risk response in order to achieve objectives, noting that legal or regulatory requirements can influence it. Other sources, following OMB Circular A-123, use it for the acceptable variance in performance relative to objectives. In practice appetite is the broad statement and tolerance the measurable limits around it.

Risk treatment

The process of selecting and implementing options to modify risk. The common options are to mitigate (apply controls), avoid (stop the activity), transfer or share (insurance, contracts) and accept. ISO/IEC 27001 requires a documented risk treatment plan. See the risk treatment plan entry.

S

Sampling

Testing a subset of a control's occurrences to draw a conclusion about the whole population. Sample size depends on how often the control runs (an annual control may have a sample of one, a daily control many more) and on the assurance needed. The population must be complete, or the sample proves nothing.

Scope (audit or ISMS scope)

The boundaries of what an audit or management system covers: business units, locations, systems, processes and the period. Narrow scopes are a common reason a certificate or report does not cover the service a customer actually uses, so buyers should read the scope statement first.

Segregation of duties (SoD)

Splitting a process so no single person can both perform and approve, or both create and conceal, a sensitive action, such as developing and deploying code or creating and paying a supplier. Where a team is too small to segregate, a detective review is the usual compensating control.

Shared responsibility model

The division of security duties between a cloud or service provider and the customer. For GRC it determines which controls can be inherited from the provider's attestation reports and which the customer must operate and evidence.

SOC 1, SOC 2 and SOC 3

The AICPA's System and Organization Controls reports on a service organisation. SOC 1 covers controls relevant to customers' financial reporting; SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality or privacy; SOC 3 is a general-use summary of a SOC 2 without the detailed tests. See SOC 1 vs SOC 2 vs SOC 3.

SOC 2 Type 1 and Type 2

A Type 1 report gives an opinion on the design of controls at a point in time; a Type 2 report also covers whether they operated effectively over a period, with the auditor's tests and any exceptions listed. Customers performing due diligence normally ask for Type 2. See the SOC 2 Guide.

Statement of Applicability (SoA)

The ISO/IEC 27001 document listing every Annex A control, whether it is included or excluded, the justification, and its implementation status. It links the risk treatment plan to the controls and is one of the first documents an auditor asks for. See the ISO 27001 Statement of Applicability Template.

Subservice organisation (carve-out and inclusive)

A provider used by a service organisation, such as a cloud host behind a SaaS product. In a SOC report it is either carved out (its controls are excluded and the reader must obtain its own report) or included (its controls are tested within the report). Carve-outs also list complementary subservice organisation controls the reader should check.

Surveillance audit

A periodic audit by the certification body between initial certification and recertification, checking that the ISMS is maintained and nonconformities have been corrected. It samples part of the scope rather than all of it.

T to Z

Third-party risk management (TPRM)

The lifecycle of identifying, assessing, contracting, monitoring and offboarding suppliers according to the risk they bring: data access, system connectivity and business dependence. It relies heavily on supplier attestation reports, questionnaires and contract terms. See the Third-Party Risk Management Guide.

Three Lines Model

The Institute of Internal Auditors' model, published in 2020 as an update to the earlier Three Lines of Defense, describing how the governing body, management (first line roles delivering products and services, second line roles providing expertise and oversight of risk) and internal audit (third line, independent assurance) work together. The IIA has since issued a newer statement of position on the model.

Test of design

An assessment of whether a control, as described, would meet its objective if operated correctly. It is usually performed by walkthrough of one instance. A control that fails a test of design is not tested for operating effectiveness.

Test of operating effectiveness

An assessment of whether a control operated as designed, consistently, throughout the audit period, normally by sampling occurrences and inspecting or re-performing them.

Threat

Any circumstance or event with the potential to adversely affect operations, assets or individuals through unauthorised access, destruction, disclosure, modification or denial of service. In a risk statement the threat is the cause, distinct from the vulnerability it exploits.

Vulnerability

A weakness in a system, process, control or implementation that a threat could exploit. In GRC usage it is broader than a software CVE and includes process weaknesses such as missing approvals.

Walkthrough

An audit procedure that traces one transaction or control instance from start to finish, with the people who perform it, to confirm the process is understood and the control is designed as described.

Frameworks and standards at a glance

Terms that are often confused

For identity and access terms, see the NHI and IAM Glossary. Related NHI Mgmt Group resources: Audit, Assurance and Compliance Guide · GRC Maturity Model · GRC Analyst Interview Questions · GRC Analyst Career Guide