| Assessment | The overall process of evaluating a specific system, control, or process. It includes planning, executing various tests or checks, and drawing conclusions about compliance, performance, or quality. |
| Attestation | A formal declaration or statement confirming the truth of something, based on the assessment and its observations. |
| Assessment Action | Specific tasks or activities within the overall Assessment. These are the actual tests, evaluations, or analyses carried out. For Compliance Framework, this is the code that runs the compliance checks. |
| Assessment Implementation | The activities performed to ensure that the control is being adhered to. |
| Assessment Template | Set of rules that can be applied to, and associated with multiple controls. |
| Assessor | Role that validates the Control Requirements. |
| Authorizing Official | Someone with the authority to formally assume responsibility for operating an information system at an acceptable level of risk. |
| Baseline | See 'Control Baseline'. |
| Catalog | See 'Control Catalog'. |
| Catalog Model | 'A structured, machine-readable representation of a Catalog of Controls' (OSCAL Terminology). |
| Compliance Framework Owner | The application owner of Compliance Framework. |
| Control | Policies and procedures designed to ensure systems are secure and/or stable and/or resilient. (aka Requirement, or Guideline) |
| Control Baseline | 'A specific set of selected security control requirements from one or more control catalogs for use in managing risks in an information system' (OSCAL Terminology). Also known as an 'Overlay'. |
| 'The set of controls that are applicable to information or an information system to meet legal, regulatory, or policy requirements, as well as address protection needs for the purpose of managing risk' (NIST 800-37) |
| Control Catalog | 'An organized collection of controls' (OSCAL Terminology) |
| Control Implementation | Activities performed to enforce a Control. |
| Control Layer | A layer of the OSCAL that consists of the Catalog Model and the Profile Model. |
| Control Objective | Statement that descibes outcome or intent related to the management or mitigation of risk in an information system or environment. They are intended to clarify intent, guide control selection, facilitate assessment, and support compliance. |
| Control Plan | |
| Control Profile | A Baseline of selected Controls from one or more Control Catalogs (OSCAL Terminology) |
| Control Owner | Role responsible for the management, implementation, and monitoring of specific security or privacy controls within an organisation. |
| Control Requirements | See 'Control' |
| Component | Entity that is the subject of a Control, eg a Virtual Machine instance. A Component's status is made up of collective results of ComponentRequirements pertaining to that Component. |
| Detective Control | A control that records that a qualifying event has taken place, usually with a view to following up with a check that the event was valid. |
| DORA | Digital Operational Resilience Act Digital Operational Resilience Act (DORA) - Regulation (EU) 2022/2554 |
| Environment | Set of conditions or circumstances under which a System operates. In OSCAL documentation, the environment can be described in the System Security Plan and the Control Profiles. |
| Finding | Identifies findings resulting from observations and risks, and can include the control objective status. |
| FINOS | Fintech Open Source Foundation. |
| Framework Author | |
| GRC | Governance, Risk and Control |
| Implementation | 'Used to express the security and privacy implementation of system or a software, hardware, or service offering.' (OSCAL Terminology) See also 'Control Implementation' and 'Assessment Implementation' |
| Implementation Layer | Provides Models for describing how controls are implemented in a specific System (OSCAL Terminology) |
| Implementation Owner | Role responsible for implementing a set of controls within a System or environment. |
| KRI | Key Risk Indicator: a metric for measuring the probability of an event and its consequences will exceed the organisation's risk appetite |
| Observation | The findings or results from an Assessment Action. These are specific details or data gathered during the testing phase. |
| OSCAL | Open Security Controls Assessment Language OSCAL - Open Security Controls Assessment Language |
| Overlay | See 'Control Baseline'. |
| Profile | See 'Control Profile'. |
| Profile Model | 'A structured machine-readable representation of a Baseline' (OSCAL Terminology) |
| Profile Author | 'Profiles are authored by an organisation that defines or governs control baselines, eg the High, Moderate, and Low baselines defined for NIST's Special Publication (SP) 800-52 controls.' (OSCAL Terminology) |
| Profile Consumers | 'Profiles are consumed by System Owners and Authorizing Officials as the basis for the System Security Plan (SSP).' (OSCAL Terminology) |
| Preventative Control | A Control that prevents an event from taking place, eg an organisational policy that prevents an S3 bucket being exposed to the internet. |
| Privacy Control | 'The administrative, technical, and physical safeguards employed within an agency to ensure compliance with applicable privacy requirements and manage privacy risks.' (OSCAL Terminology) |
| Reactive Control | A Control that takes corrective action when an event takes place, eg shutting down a VM that has attached an unencrypted disk. |
| Requirement | See Control |
| Risk | Identifies individual risks, including weakness description, risk statement, and other risk characteristics. |
| Risk Level | Severity of risk, eg Acceptable, Critical, Low/Moderate/High Impact |
| RPO | Recovery Point Objective |
| Senior Management Function 24 | The person in an organisation held responsible for operational failings. |
| Security Control | 'The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information.' (OSCAL Terminology) |
| SSP | See 'System Security Plan'. |
| System | Group of components. A system can be horizonal or vertical. Horizontal is organisationally cross-cutting, for example 'Azure'. Vertical is a grouping for an organisational vertical, eg an application. |
| System Owner | Implementors of controls. |
| System Security Plan | A description of the control implementation of an information system. |
| SMF24 | See 'Senior Management Function 24' |
| Variance | Deviations or exceptions from established security standards, policies, or procedures. |