Controls, Risk and Compliance

What it is

A control is any measure that reduces risk, whether it is a technology, a rule or a physical barrier. Risk is the chance that a threat uses a weakness, combined with the harm that would result.

Vulnerability management sits inside this larger frame. Scan findings become risk decisions, and policies and laws set how fast and how thoroughly the organisation must respond.

How it works

Control categories and types

Controls can be described in two ways: by who or what operates them, and by what they do.

A single control can fit more than one type. A camera is both a deterrent and a detective control.

Responsive controls. The exam objectives list four control functions: preventive, detective, responsive and corrective. A responsive control is the immediate reaction while an incident is under way, such as isolating a host, blocking an address, disabling an account or starting the incident response plan. A corrective control repairs the damage and restores normal operation afterwards, for example restoring from backup or applying the missing patch.

When both appear in the same question, responsive is the immediate containment during the incident and corrective is the repair afterwards.

Risk responses

Transfer moves the cost, but not the responsibility for protecting the data. Inherent risk is the level before controls and residual risk is what is left after them. Risk appetite is how much risk the organisation is willing to take to reach its goals, and risk tolerance is the acceptable variation around it.

Measuring risk

Qualitative assessment ranks risk with labels such as low, medium and high on a matrix of likelihood and impact. Quantitative assessment uses numbers.

• Single loss expectancy (SLE) is the cost of one occurrence.
• Annualised rate of occurrence (ARO) is how many times per year it is expected.
• Annualised loss expectancy (ALE) is SLE multiplied by ARO.

For example, an SLE of 20,000 with an ARO of 0.5 gives an ALE of 10,000 per year. A control that costs much more per year than the ALE it removes is hard to justify.

A risk register lists risks, owners, ratings, responses and status, and it gives vulnerability findings that cannot be fixed immediately a place to be tracked.

Policies, standards and procedures

A vulnerability management policy typically defines scope, scan frequency, roles, remediation time targets by severity, how exceptions are approved and how results are reported.

Compliance drivers

Laws, contracts and standards can require specific practices. Examples include the Payment Card Industry Data Security Standard (PCI DSS), the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR). PCI DSS, for instance, expects regular vulnerability scanning and requires external scans to be carried out by an approved scanning vendor.

Frameworks give structure without being laws. Examples are the National Institute of Standards and Technology (NIST) Cybersecurity Framework, and ISO/IEC 27001 from the International Organization for Standardization and the International Electrotechnical Commission for security management systems. Organisations use them for design and audit, and compliance activity depends on which rules apply to their data and sector.

Compliance is a minimum, not a guarantee of security. Evidence such as scan reports, remediation records and approved exceptions is what an auditor asks for.

Data and asset context

Data classification (for example public, internal, confidential) tells you what a system holds and how strictly it must be protected. Asset criticality and classification feed directly into scan scope and remediation urgency.

Application security maturity

The Software Assurance Maturity Model (SAMM) from the Open Worldwide Application Security Project (OWASP) helps an organisation assess and improve how it builds secure software. It covers five business functions: governance, design, implementation, verification and operations. Where static and dynamic application security testing and software composition analysis test software, SAMM measures the maturity of the whole programme and guides a roadmap.

Supply chain risk and the SBOM

Supply chain risk comes from suppliers and the software or services they provide. Examples are a compromised vendor update, a vulnerable open source library inside your product, and a vendor breach that exposes your data.

• Assess vendors before and during the contract, using questionnaires and evidence such as audit reports.
• Put security terms in contracts, such as breach notification times, patching duties and the right to audit.
• Give vendors least privilege access and monitor it.
• Verify the integrity of downloaded software with hashes or signatures.

A software bill of materials (SBOM) is an inventory of the components and versions inside a piece of software, like an ingredients list. Common formats are Software Package Data Exchange (SPDX) and CycloneDX.

{"bomFormat": "CycloneDX", "components": [{"type": "library", "name": "log4j-core", "version": "2.14.1"}]}

When a library flaw is announced, searching the SBOMs shows which products contain the affected version, so the team does not have to guess. The SBOM lists components only, so match them against vulnerability data.