Vulnerability Management Procedure

1. Purpose

The purpose of this procedure is to establish a consistent process for identifying, assessing, prioritizing, remediating, verifying, and monitoring vulnerabilities that may affect the organization’s information systems, applications, infrastructure, cloud environment, devices, and information assets.

The objective is to reduce the likelihood and impact of vulnerabilities being exploited and to ensure that vulnerabilities are managed according to their actual risk to the organization.

2. Scope

This procedure applies to relevant:

Applications
Web applications
APIs
Servers
Endpoints
Network devices
Cloud infrastructure
Databases
Containers
Operating systems
Software components
Mobile applications
Third-party systems where applicable
Open-source software
Development environments
Production environments
Information systems managed by suppliers

The procedure applies to:

IT
Engineering
Cloud / Infrastructure
Security
DevOps
Application owners
System owners
Risk owners
Relevant suppliers

3. What Is a Vulnerability?

A vulnerability is a weakness in a system, application, configuration, process, or technology that could potentially be exploited by a threat actor.

Examples include:

Unpatched software
Unsupported operating systems
Weak authentication
Excessive privileges
Misconfigured cloud resources
Exposed services
Application security flaws
Insecure APIs
Vulnerable third-party libraries
Weak encryption configuration
Missing security controls
Insecure default configurations

A vulnerability does not automatically mean that an incident has occurred.

The organization should assess whether the vulnerability is actually relevant and what risk it creates.

4. Vulnerability Management Lifecycle

The organization’s vulnerability management process should follow:

Identify Assets
↓
Discover Vulnerabilities
↓
Validate Findings
↓
Assess Risk
↓
Prioritize
↓
Remediate / Mitigate / Accept
↓
Verify Remediation
↓
Record Evidence
↓
Monitor and Reassess

5. Asset Identification

Effective vulnerability management requires an understanding of the organization’s technology environment.

Relevant assets should be identified through sources such as:

Asset inventory
Cloud inventory
CMDB
Endpoint management
Application inventory
Software inventory
Network discovery
Container registries
Infrastructure-as-code repositories
Supplier information

For a cloud-based organization, the inventory may include:

AWS accounts
EC2 instances
RDS databases
S3 buckets
Lambda functions
Containers
APIs
Load balancers
IAM identities
Security groups
Applications

6. Vulnerability Identification

Vulnerabilities may be identified through:

Vulnerability scanning
VAPT
Penetration testing
Application security testing
Dependency scanning
Container scanning
Cloud security tools
Endpoint security tools
Patch management
Code scanning
Security advisories
Threat intelligence
Vendor notifications
Security incidents
Internal audits
Customer security assessments

The organization should select appropriate methods based on its technology environment and risk.

7. Vulnerability Scanning

Vulnerability scanning may be performed periodically or continuously, depending on the organization’s environment.

Scanning may cover:

Infrastructure

Servers
Network devices
Operating systems
Cloud infrastructure

Applications

Web applications
APIs
Mobile applications

Software

Open-source dependencies
Third-party libraries
Container images

Cloud

Misconfigurations
Public exposure
Identity and access configuration
Security groups
Storage configuration

Scanning frequency should be determined based on risk.

A startup may establish, for example:

Environment	Example Frequency
Internet-facing production systems	Continuous / frequent
Production infrastructure	Monthly
Internal systems	Monthly / Quarterly
Applications	Before major release + periodic testing
Dependencies	During CI/CD
Containers	During build/deployment
Critical systems	Risk-based continuous monitoring

These are examples and should be adjusted to the organization’s environment.

8. Vulnerability Sources

The organization should consider information from:

Security scanners
Penetration tests
VAPT reports
Software vendors
Cloud providers
Security advisories
Threat intelligence
Vulnerability databases
Developers
Employees
Customers
Suppliers

External threat intelligence should be incorporated when it changes the practical risk of a vulnerability.

9. Vulnerability Validation

Not every scanner finding represents a confirmed vulnerability.

Findings should be reviewed to determine:

Whether the affected asset actually exists
Whether the affected software/version is present
Whether the vulnerability is applicable
Whether the finding is a false positive
Whether compensating controls exist
Whether the system is exposed
Whether exploitation is possible
Whether remediation is required

Where appropriate, technical validation or manual testing should be performed.

10. Vulnerability Severity

Vulnerabilities may initially be classified using an established severity framework such as CVSS where applicable.

However, the organization should not rely solely on a technical severity score.

The final priority should consider organizational context.

Relevant factors include:

Vulnerability severity
Exploit availability
Active exploitation
Internet exposure
Asset criticality
Data sensitivity
Customer impact
Regulatory impact
Existing controls
Business impact
Ease of exploitation

11. Vulnerability Prioritization

A practical priority model is:

Priority	Typical Situation	Expected Action
Critical	Critical vulnerability + significant exposure / active exploitation	Immediate action
High	Significant vulnerability affecting important or exposed assets	Prompt remediation
Medium	Moderate risk with limited exposure	Planned remediation
Low	Limited impact or exposure	Address through normal maintenance

The exact remediation targets should be defined by the organization based on its risk appetite and operational environment.

12. Example Remediation Targets

An organization may establish internal target timelines such as:

Priority	Example Target
Critical	24–72 hours
High	7–14 days
Medium	30–60 days
Low	90 days / planned maintenance

These are examples rather than universal ISO requirements.

The organization should formally define its own targets based on risk.

If immediate remediation is not possible, the vulnerability should be documented, risk-assessed, and managed through mitigation, compensating controls, or formal risk acceptance where appropriate.

13. Vulnerability Remediation

Remediation may include:

Applying security patches
Updating software
Upgrading dependencies
Changing configurations
Removing vulnerable components
Disabling vulnerable services
Restricting network access
Strengthening authentication
Implementing additional monitoring
Applying compensating controls
Replacing unsupported technology

Remediation should follow the organization’s change management process where applicable.

14. Vulnerability Mitigation

Sometimes immediate remediation is not technically or operationally possible.

Temporary mitigation may include:

Network segmentation
Firewall restrictions
Disabling vulnerable functionality
Removing internet exposure
Access restrictions
Additional authentication
Increased monitoring
Web application firewall rules
Temporary service isolation

Mitigation should have:

An owner
Target date
Review date
Defined residual risk
Follow-up remediation plan where required

Temporary mitigation should not become an indefinite substitute for remediation without appropriate risk review.

15. Risk Acceptance

A vulnerability may be formally accepted only when the organization determines that the remaining risk is within its defined risk acceptance criteria.

The acceptance should identify:

Vulnerability
Affected asset
Risk
Reason for acceptance
Existing controls
Residual risk
Risk owner
Approval
Acceptance date
Expiry/review date

Risk acceptance should not be used simply because remediation is inconvenient.

16. Vulnerability Verification

After remediation, the organization should verify that the vulnerability has actually been addressed.

Verification methods may include:

Rescanning
Manual testing
Configuration review
Version verification
Penetration testing
Application security testing
Code review
Deployment verification

Example:

Vulnerability detected → Patch applied → Application redeployed → Vulnerability scan repeated → Finding no longer detected → Ticket closed

Evidence of verification should be retained.

17. False Positives

Where a vulnerability is determined to be a false positive, the finding should be documented appropriately.

The record may include:

Finding
Asset
Reason for false positive
Technical evidence
Validation performed
Person who reviewed it
Date reviewed

False-positive decisions should be periodically reassessed where the underlying environment changes.

18. Vulnerability Register

The organization should maintain a vulnerability register or equivalent ticketing system.

Recommended fields include:

Field	Description
Vulnerability ID	Unique reference
Date Identified	Detection date
Source	Scanner / VAPT / Advisory / Other
Asset	Affected system
Vulnerability	Description
CVE / Identifier	Where applicable
Severity	Technical severity
Organizational Risk	Business risk
Exposure	Internet / Internal / Restricted
Exploit Available	Yes / No / Unknown
Priority	Critical / High / Medium / Low
Action	Remediation / Mitigation / Acceptance
Owner	Responsible person
Target Date	Remediation target
Status	Open / In Progress / Closed
Verification	Validation method
Evidence	Supporting record
Closure Date	Date closed

19. Example Vulnerability Register

ID	Asset	Vulnerability	Severity	Priority	Action	Owner	Status
VUL-001	Production API	Critical library vulnerability	Critical	Critical	Upgrade dependency	Engineering	Closed
VUL-002	EC2 Server	Missing security patch	High	High	Apply patch	Cloud Team	In Progress
VUL-003	Internal Laptop	Outdated application	Medium	Medium	Update software	IT	Closed
VUL-004	Test Server	Unsupported software	High	Medium	Isolate / replace	IT	Open

20. AWS SaaS Startup Example

Consider a SaaS company operating its application on AWS.

A vulnerability scanner identifies a critical vulnerability in a library used by the production application.

Step 1 – Identification

The vulnerability is identified through dependency scanning.

Step 2 – Validation

Engineering confirms that the affected library is actually deployed.

Step 3 – Risk Assessment

The Security Lead determines:

The application is internet-facing.
The vulnerability is actively exploitable.
Customer information is processed by the application.

The vulnerability is therefore treated as high priority.

Step 4 – Remediation

Engineering upgrades the vulnerable library and deploys the updated application.

Step 5 – Verification

Security performs a new scan and confirms that the vulnerable version is no longer present.

Step 6 – Evidence

The organization retains:

Scanner report
Vulnerability ticket
Risk assessment
Pull request / code change
Deployment record
Rescan result

Step 7 – Risk Review

The related application security risk is reviewed and updated where necessary.

21. Emergency Vulnerability Response

Immediate escalation should occur when:

A critical vulnerability is actively exploited.
A critical internet-facing system is affected.
Customer data may be exposed.
Credentials may be compromised.
A vulnerability is being actively targeted.
Normal remediation timelines cannot adequately reduce the risk.

The organization should coordinate with the Incident Management Procedure when there is evidence that exploitation may already have occurred.

22. Vulnerability Management and Threat Intelligence

Threat intelligence should influence vulnerability prioritization.

For example:

Vulnerability identified
+
Active exploitation reported
+
Organization is exposed

Higher remediation priority

This ensures that vulnerability management considers the actual threat environment rather than relying only on scanner severity.

23. Vulnerability Management and Risk Management

The relationship can be represented as:

Vulnerability
→ Threat
→ Potential Impact
→ Risk Assessment
→ Treatment Decision
→ Control / Remediation
→ Residual Risk

A vulnerability register should not replace the organization’s Risk Register.

The vulnerability register tracks technical weaknesses and their remediation, while the Risk Register manages broader information security risks.

24. Third-Party Vulnerabilities

Where critical suppliers or third-party services are involved, the organization should consider:

Supplier security advisories
Software vulnerabilities
Cloud provider vulnerabilities
Third-party application vulnerabilities
Open-source dependencies
Managed service vulnerabilities

Where a supplier controls the remediation, the organization should:

Notify or contact the supplier.
Request relevant remediation information.
Assess the organization’s exposure.
Apply available compensating controls.
Track the supplier’s response.
Reassess the risk.

25. Vulnerability Management in Secure Development

For software development environments, vulnerability management should be integrated into the SDLC.

Potential activities include:

Software composition analysis
Dependency scanning
Static application security testing
Dynamic application security testing
Container scanning
Infrastructure-as-code scanning
Secret scanning
Code review
Penetration testing

Security findings should be tracked through the organization’s development workflow.

26. Roles and Responsibilities

Top Management

Support appropriate vulnerability management resources.
Review significant unresolved vulnerabilities.
Support risk decisions where required.

Security / ISMS Manager

Maintain the vulnerability management process.
Monitor significant vulnerabilities.
Coordinate risk assessment.
Track critical/high findings.
Escalate overdue risks.

IT / Cloud Team

Maintain infrastructure.
Apply operating system and infrastructure patches.
Remediate configuration vulnerabilities.

Engineering / DevOps

Remediate application and dependency vulnerabilities.
Integrate security testing into development.
Provide remediation evidence.

Asset / System Owners

Assess business impact.
Prioritize remediation.
Ensure vulnerabilities are addressed.

Risk Owners

Evaluate residual risk.
Approve risk treatment or acceptance where appropriate.

27. Metrics

The organization may monitor:

Number of open vulnerabilities
Critical vulnerabilities
High vulnerabilities
Average remediation time
Overdue vulnerabilities
Vulnerabilities by asset
Vulnerabilities by business unit
Recurring vulnerabilities
Vulnerabilities identified through VAPT
Vulnerabilities identified through scanning
Percentage remediated within target
Number of accepted vulnerabilities
Number of false positives
Number of vulnerabilities identified through threat intelligence

Example management metric:

Critical/High Vulnerabilities Open > Target Date

This can be presented during management review.

28. Reporting and Escalation

The Security / ISMS Manager should periodically report significant vulnerability information to relevant management.

Reports may include:

Critical open vulnerabilities
High-risk overdue vulnerabilities
Major trends
Recurring weaknesses
Remediation performance
Accepted risks
Supplier vulnerabilities
Vulnerability trends

Critical vulnerabilities should be escalated immediately rather than waiting for the periodic report.

29. Evidence and Records

Possible audit evidence includes:

Vulnerability scan reports
VAPT reports
Penetration testing reports
Dependency scan results
Cloud security findings
Vulnerability register
Remediation tickets
Patch records
Pull requests
Change records
Configuration evidence
Rescan results
Risk acceptance records
Risk Register
Threat intelligence reports
Management reports

30. Review and Continual Improvement

The vulnerability management process should be periodically reviewed.

The review should consider:

Are important assets being scanned?
Are critical vulnerabilities identified promptly?
Are remediation timelines being met?
Are recurring vulnerabilities occurring?
Are false positives being managed?
Are vulnerability sources sufficient?
Is threat intelligence being incorporated?
Are suppliers providing adequate vulnerability information?
Are remediation controls effective?

Lessons from incidents, audits, penetration tests, and vulnerability trends should be used to improve the process.

31. Quick Audit Checklist

Audit Question	Evidence
Are technology assets identified?	Asset inventory
Is vulnerability scanning performed where appropriate?	Scan reports
Are applications and dependencies assessed?	SAST/SCA/DAST results
Are vulnerabilities validated?	Review records
Is risk considered in prioritization?	Risk assessment
Are critical vulnerabilities escalated?	Escalation records
Are remediation targets defined?	Vulnerability procedure
Are vulnerabilities assigned to owners?	Vulnerability register
Are remediation actions tracked?	Tickets
Are temporary mitigations documented?	Mitigation records
Are accepted risks formally approved?	Risk acceptance
Is remediation verified?	Rescan/testing evidence
Are overdue vulnerabilities monitored?	Management reports
Are supplier vulnerabilities considered?	Supplier records
Is threat intelligence used?	Threat intelligence records
Is the process periodically reviewed?	Review / improvement records

32. Relationship With Other ISMS Documents

The Vulnerability Management Procedure should connect with:

Asset Management
→ Identifies systems and assets that need protection.

Threat Intelligence Procedure
→ Provides information about active threats and exploitation.

Risk Assessment / Risk Register
→ Determines business risk associated with vulnerabilities.

Secure Development Procedure
→ Manages application and software vulnerabilities.

Patch Management
→ Implements technical remediation.

Change Management
→ Controls production changes resulting from remediation.

Incident Management Procedure
→ Handles suspected or confirmed exploitation.

Supplier Security Management
→ Manages vulnerabilities involving third parties.

Corrective Action Process
→ Tracks systemic or recurring security weaknesses.

Management Review
→ Reviews significant vulnerabilities and remediation performance.

33. Startup-Friendly Implementation

A startup does not need a complex vulnerability management platform on day one.

A practical approach is:

1. Maintain an accurate asset inventory
↓
2. Identify appropriate scanning/testing methods
↓
3. Scan critical systems and applications
↓
4. Validate findings
↓
5. Prioritize based on severity + exposure + business impact
↓
6. Assign an owner and target date
↓
7. Remediate or mitigate
↓
8. Verify the fix
↓
9. Update risk records where necessary
↓
10. Report significant overdue vulnerabilities
↓
11. Review trends and improve

The objective is not to achieve zero vulnerabilities at every moment.

The objective is to ensure that vulnerabilities are known, risk-assessed, prioritized, treated, verified, and appropriately accepted where necessary.

Final Principle

Discover → Validate → Assess → Prioritize → Remediate → Verify → Record → Improve

ISO/IEC 27001