Risk Management and Security Governance: Policies, Compliance, and Third-Party Risk
By William E. Coe Jr.
Introduction
Cybersecurity is not only about technology.
Firewalls, encryption, endpoint protection, authentication, security monitoring, and other technical controls are important, but technology alone cannot protect an organization.
Organizations also need to decide:
* What information needs protection?
* What could go wrong?
* How much risk is acceptable?
* Who is responsible for security?
* What rules must employees follow?
* Which laws and regulations apply?
* How should security incidents be handled?
* What happens when a third-party company has access to organizational information?
These questions are part of **risk management and security governance**.
For someone beginning to study cybersecurity, governance and risk management can sometimes seem less interesting than topics such as malware or network security. However, these concepts are extremely important because they provide the structure behind an organization’s security program.
A company can purchase excellent security technology and still have serious security problems if it does not have appropriate policies, procedures, risk assessments, accountability, and oversight.
This article introduces the fundamentals of cybersecurity risk management, security governance, policies, compliance, risk treatment, business impact, and third-party risk.
— -
What Is Risk?
In cybersecurity, **risk** is the possibility that a threat will take advantage of a vulnerability and cause harm.
A simple way to think about risk is:
**Threat + Vulnerability + Potential Impact = Risk**
For example, imagine that a company has an internet-facing server with an unpatched vulnerability.
The **vulnerability** is the weakness.
An attacker capable of exploiting the vulnerability represents the **threat**.
The potential consequences could include:
* Data theft
* System downtime
* Financial loss
* Reputation damage
* Regulatory consequences
The combination creates a cybersecurity risk.
— -
Threats, Vulnerabilities, and Risk
These terms are closely related but should not be confused.
Threat
A **threat** is something capable of causing harm.
Examples include:
* Cybercriminals
* Malware
* Insider threats
* Natural disasters
* Hardware failures
Vulnerability
A **vulnerability** is a weakness that could be exploited or otherwise cause harm.
Examples include:
* Unpatched software
* Weak passwords
* Misconfigured cloud storage
* Excessive permissions
* Unsupported software
Risk
**Risk** considers the possibility of harm resulting from threats and vulnerabilities.
For example:
> An attacker could exploit an unpatched internet-facing server and gain unauthorized access to sensitive information.
That represents a cybersecurity risk.
— -
Asset Identification
Before an organization can manage risk, it needs to understand what it is protecting.
An **asset** is something valuable to an organization.
Assets can include:
* Servers
* Laptops
* Network equipment
* Applications
* Databases
* Intellectual property
* Customer information
* Financial information
* Credentials
* Cloud resources
* Physical facilities
Asset identification is important because organizations cannot effectively protect something they have not identified.
Imagine a company discovers an old server that is still connected to the network.
Nobody knows who owns it, what information it contains, or why it is still operating.
That creates unnecessary risk.
— -
Asset Classification
Organizations often classify information according to its sensitivity or importance.
For example, an organization might classify information as:
* Public
* Internal
* Confidential
* Restricted
The exact categories vary between organizations.
Classification helps determine how information should be handled.
Highly sensitive information may require stronger:
* Access controls
* Encryption
* Monitoring
* Retention requirements
* Disposal procedures
For example, a company’s public website content may not require the same level of protection as customer financial information.
— -
Risk Assessment
A **risk assessment** is the process of identifying and evaluating risks.
An organization may examine:
* Assets
* Threats
* Vulnerabilities
* Likelihood
* Potential impact
* Existing controls
Suppose a company identifies a vulnerability in an internet-facing application.
Security personnel may ask:
**How likely is this vulnerability to be exploited?**
and:
**What would happen if it were successfully exploited?**
These questions help determine how the organization should respond.
— -
Likelihood and Impact
Two important concepts in risk analysis are **likelihood** and **impact**.
Likelihood
Likelihood describes how probable it is that an event will occur.
Impact
Impact describes how serious the consequences would be if the event occurred.
A risk with a relatively high likelihood and severe impact may require significant attention.
For example, suppose a critical business application has a known vulnerability that is actively being exploited by attackers.
The likelihood may be high, and the potential impact could also be high.
This information can help security personnel prioritize remediation.
— -
Qualitative Risk Analysis
**Qualitative risk analysis** uses descriptive categories rather than exact monetary values.
An organization might classify risks as:
* Low
* Moderate
* High
* Critical
For example:
| Risk | Likelihood | Impact |
| — — — — — — — — — — — — — — — — — — — | — — — — — | — — — |
| Outdated workstation | Medium | Low |
| Compromised administrator account | Medium | High |
| Internet-facing critical vulnerability | High | High |
The categories help decision-makers understand relative risk.
— -
Quantitative Risk Analysis
**Quantitative risk analysis** attempts to assign numerical values to risk.
For example, an organization may estimate the financial impact of a particular incident.
A simplified example could involve:
**Asset Value × Exposure Factor = Single Loss Expectancy**
The **Single Loss Expectancy (SLE)** represents the estimated loss from one occurrence of a risk event.
Organizations can also estimate the expected annual frequency of an event.
This can lead to the concept of:
**Annualized Loss Expectancy (ALE)**
A simplified relationship is:
**SLE × Annual Rate of Occurrence = ALE**
These calculations can help organizations compare potential losses with the cost of security controls.
The numbers are estimates, so they should not be treated as perfect predictions.
— -
Risk Treatment
Once an organization identifies a risk, it needs to decide what to do about it.
Common risk treatment strategies include:
* **Risk avoidance**
* **Risk mitigation**
* **Risk transfer**
* **Risk acceptance**
Understanding these four concepts is important for Security+ students.
— -
Risk Avoidance
**Risk avoidance** means changing the situation so that the risk no longer exists or is no longer applicable.
For example, an organization might decide not to deploy a particular application because its security requirements cannot be adequately met.
If the organization never uses the application, the risks associated with that application may be avoided.
Avoidance can sometimes be expensive or impractical, so organizations need to evaluate the business consequences.
— -
Risk Mitigation
**Risk mitigation** means reducing the likelihood or impact of a risk.
For example, an organization identifies a risk associated with stolen passwords.
It may implement:
* MFA
* Strong password policies
* Account lockout controls
* Monitoring
* Conditional access
These controls may reduce the likelihood or impact of account compromise.
Mitigation is one of the most common approaches to cybersecurity risk.
— -
Risk Transfer
**Risk transfer** means shifting some of the financial or operational consequences of a risk to another party.
Cybersecurity insurance is one example.
An organization may purchase insurance to help cover certain costs associated with a qualifying security incident.
Another example may involve a contractual arrangement in which a third party accepts specific responsibilities or liabilities.
Risk transfer does not necessarily eliminate the underlying security risk.
The organization may still have responsibilities.
— -
Risk Acceptance
Sometimes an organization decides to **accept** a risk.
This does not necessarily mean that the organization believes the risk is harmless.
Instead, decision-makers determine that the cost of addressing the risk may be greater than the expected benefit, or that the risk falls within an acceptable level.
Risk acceptance should generally be a deliberate business decision.
For example, replacing a very old but low-value piece of equipment might cost more than the organization’s estimated exposure justifies.
The organization may formally accept the risk for a defined period.
— -
Risk Register
A **risk register** is a documented record of identified risks.
A risk register may contain information such as:
* Risk description
* Affected asset
* Threat
* Vulnerability
* Likelihood
* Impact
* Risk level
* Risk owner
* Treatment strategy
* Planned controls
* Status
* Review date
The risk register helps organizations track risks over time.
Risk management should not be treated as a one-time activity.
New vulnerabilities, technologies, business processes, and threats can change the organization’s risk environment.
— -
Risk Owners
A **risk owner** is the person or group responsible for managing a particular risk.
This does not necessarily mean that the risk owner personally fixes the technical problem.
For example, an IT security team may implement a technical control, while a business manager remains responsible for accepting or addressing the business risk.
Clearly assigning ownership prevents important risks from becoming everyone’s responsibility and therefore nobody’s responsibility.
— -
Security Governance
**Security governance** provides the structure through which an organization directs and oversees cybersecurity.
Governance helps establish:
* Security responsibilities
* Policies
* Accountability
* Risk management
* Compliance requirements
* Security objectives
* Leadership oversight
Governance answers an important question:
> **How does an organization make and enforce decisions about security?**
Technical security controls operate within this larger framework.
— -
Security Policies
A **security policy** establishes high-level rules and expectations.
For example, an organization’s acceptable use policy might define appropriate use of company computers and networks.
Other security policies might address:
* Passwords
* Access control
* Remote access
* Mobile devices
* Data classification
* Encryption
* Incident response
* Acceptable use
* Change management
* Third-party access
Policies help establish what employees and administrators are expected to do.
— -
Standards
A **standard** provides specific requirements that support a policy.
For example:
**Policy:**
Employees must use strong authentication.
**Standard:**
Administrative accounts must use MFA and meet defined authentication requirements.
Get William E. Coe Jr.’s stories in your inbox
Join Medium for free to get updates from this writer.
Standards are generally more specific than policies.
They help turn broad security expectations into measurable requirements.
— -
Procedures
A **procedure** provides detailed instructions for performing a task.
For example, an organization may have a procedure describing exactly how an administrator should create a new employee account.
The procedure might specify:
1. Verify the employee’s identity.
2. Confirm the manager’s authorization.
3. Create the account.
4. Assign the appropriate role.
5. Enable MFA.
6. Document the account creation.
7. Notify the appropriate personnel.
Procedures help ensure that tasks are performed consistently.
— -
Guidelines
A **guideline** provides recommendations or suggested practices.
Unlike a mandatory policy or standard, a guideline may provide flexibility.
For example, an organization could publish guidelines recommending secure practices for working from home.
Guidelines can help employees make better security decisions without necessarily functioning as strict mandatory requirements.
— -
Policies, Standards, Procedures, and Guidelines
A useful way to remember these concepts is:
**Policy → What the organization requires**
**Standard → Specific mandatory requirements**
**Procedure → How to perform the task**
**Guideline → Recommended approach**
Understanding these distinctions can make Security+ questions easier.
— -
Security Awareness and Training
Employees are an important part of an organization’s security program.
Security awareness training can teach employees how to recognize:
* Phishing
* Social engineering
* Suspicious attachments
* Malicious links
* Credential theft
* Physical security threats
* Unsafe data handling
Training should not be limited to telling employees:
> “Don’t click suspicious links.”
Effective awareness programs explain **why** the behavior matters and give employees practical ways to identify and report suspicious activity.
— -
Compliance
**Compliance** means meeting applicable requirements.
Requirements may come from:
* Laws
* Regulations
* Contracts
* Industry standards
* Organizational policies
* Customer requirements
Compliance is important, but it should not be confused with complete security.
An organization can meet a particular compliance requirement and still have security vulnerabilities.
Compliance establishes required controls or practices, while security involves managing the organization’s broader risks.
— -
Privacy and Data Protection
Organizations may have responsibilities regarding personal information.
Sensitive information can include:
* Names
* Addresses
* Financial information
* Medical information
* Identification information
* Account information
Organizations should understand what data they collect, why they collect it, where it is stored, who can access it, and how long it should be retained.
Security controls can help protect personal information from unauthorized access or disclosure.
— -
Data Retention
**Data retention** refers to how long an organization keeps information.
Keeping information forever is not always a good security practice.
The more information an organization stores, the more information could potentially be exposed during a security incident.
Organizations may establish retention periods based on:
* Business requirements
* Legal requirements
* Regulatory requirements
* Contracts
* Operational needs
When information is no longer required, it may need to be securely disposed of.
— -
Data Disposal
Secure disposal helps prevent sensitive information from being recovered by unauthorized individuals.
Depending on the type of media, disposal methods may include:
* Secure deletion
* Cryptographic erasure
* Degaussing
* Shredding
* Physical destruction
The appropriate method depends on the storage technology and sensitivity of the information.
For example, simply deleting a file may not guarantee that the underlying data cannot be recovered.
— -
Third-Party Risk
Modern organizations rarely operate entirely on their own.
They may depend on:
* Cloud providers
* Software vendors
* Managed service providers
* Contractors
* Payment processors
* Consultants
* Data-processing companies
These organizations may have access to company systems or information.
This creates **third-party risk**.
A company may have excellent internal security but still be exposed if an important vendor has poor security practices.
— -
Vendor Risk Management
Organizations can evaluate third parties before granting them access to sensitive systems or information.
This process may include:
* Security questionnaires
* Contract requirements
* Security assessments
* Certifications
* Audit reports
* Penetration-testing information
* Data protection requirements
* Incident notification requirements
Organizations may also continue monitoring important vendors after the relationship begins.
Third-party risk should not be treated as a one-time check.
— -
Contracts and Security Requirements
Contracts can establish security expectations for third parties.
For example, a contract might specify that a vendor must:
* Protect customer information
* Use appropriate access controls
* Report security incidents
* Maintain security safeguards
* Limit access to authorized personnel
* Properly dispose of data
* Meet specific compliance requirements
Contracts can help clarify responsibilities before an incident occurs.
— -
Supply Chain Risk
Organizations also need to consider the **supply chain**.
A company may depend on software and hardware produced by many other organizations.
A weakness somewhere in that supply chain can create security consequences for the final organization.
For example, a compromised software update could potentially distribute malicious code to many customers.
Supply chain security therefore involves understanding where technology comes from and what risks may exist throughout the process.
— -
Business Impact Analysis
A **Business Impact Analysis (BIA)** examines the potential effects of disruptions to important business processes.
The organization may identify:
* Critical systems
* Critical applications
* Important data
* Dependencies
* Maximum tolerable downtime
* Recovery requirements
For example, a company’s online payment system may be much more critical than an internal application used only occasionally.
The BIA helps the organization prioritize recovery and continuity efforts.
— -
Recovery Time Objective
A **Recovery Time Objective (RTO)** defines the targeted amount of time within which a system or business function should be restored after disruption.
For example:
> RTO = 4 hours
This means the organization has established a recovery target of four hours for that particular service.
RTO is about **time**.
— -
Recovery Point Objective
A **Recovery Point Objective (RPO)** focuses on how much data loss is acceptable, measured in time.
For example:
> RPO = 1 hour
This means the organization may be willing to lose up to approximately one hour of data, depending on the implementation.
A useful way to remember the distinction is:
**RTO → How quickly must we recover?**
**RPO → How much recent data can we afford to lose?**
These concepts are important when designing backup and recovery strategies.
— -
Security Governance and Incident Response
Governance also influences how organizations respond to incidents.
An incident response policy may establish:
* Who can declare an incident
* Who must be notified
* Who has authority to isolate systems
* How evidence should be handled
* When legal personnel should be involved
* How incidents should be documented
* How external communications should be managed
Without clear governance, incident response can become chaotic.
This is another example of how cybersecurity technology and organizational processes work together.
— -
Continuous Risk Management
Risk management should not happen only once a year.
Organizations constantly change.
They may:
* Deploy new applications
* Move systems to the cloud
* Hire new employees
* Acquire companies
* Add vendors
* Replace infrastructure
* Discover vulnerabilities
* Face new threats
Each change can affect risk.
Continuous risk management helps organizations identify and address these changes.
— -
Security+ Study Alignment
Risk management and security governance connect to many important Security+ concepts.
For the **SY0–701** exam, students should be comfortable with concepts such as:
* Risk identification
* Risk assessment
* Threats
* Vulnerabilities
* Assets
* Likelihood
* Impact
* Qualitative risk analysis
* Quantitative risk analysis
* Risk avoidance
* Risk mitigation
* Risk transfer
* Risk acceptance
* Risk register
* Risk ownership
* Security governance
* Policies
* Standards
* Procedures
* Guidelines
* Security awareness
* Compliance
* Data retention
* Data disposal
* Third-party risk
* Vendor risk management
* Supply chain risk
* Business Impact Analysis
* RTO
* RPO
* Business continuity
* Disaster recovery
A useful way to study these concepts is to think about them as a chain:
**Identify assets → Identify threats → Identify vulnerabilities → Assess risk → Select treatment → Implement controls → Monitor → Reassess**
This represents the ongoing nature of cybersecurity risk management.
— -
Conclusion
Cybersecurity is not simply a technical problem.
Organizations need technology, but they also need people, policies, processes, accountability, and leadership.
Risk management helps organizations understand what could go wrong and determine how those risks should be addressed.
Security governance establishes the structure for making security decisions.
Policies establish expectations.
Standards create specific requirements.
Procedures explain how tasks should be performed.
Guidelines provide recommended practices.
Compliance helps organizations meet applicable legal, regulatory, contractual, or industry requirements.
Third-party risk management helps organizations understand the security risks introduced by vendors and service providers.
Business impact analysis helps organizations understand which systems and processes are most important when something goes wrong.
The most important lesson for a Security+ student is that **security decisions should be based on risk**.
An organization cannot eliminate every possible threat. Instead, it must identify important risks, prioritize them, implement appropriate controls, monitor the environment, and continually reassess its security posture.
Cybersecurity is therefore an ongoing process.
Technology changes.
Threats change.
Businesses change.
And the organization’s security program must change with them.
Understanding risk management and governance provides a foundation for understanding how all the other Security+ topics — network security, identity, cryptography, endpoint security, cloud security, monitoring, and incident response — fit together into a complete cybersecurity program.
— -
William E. Coe Jr.
