Vulnerability Management Procedure

1. Purpose

This procedure establishes a systematic approach for identifying, assessing, prioritizing, and remediating security vulnerabilities in Swedwise AB's information systems, applications, and infrastructure. It ensures that vulnerabilities are addressed in a timely manner to reduce security risk and maintain compliance with ISO 27001 requirements.

2. Scope

This procedure applies to:

• All Swedwise-managed systems and infrastructure
• Cloud services (Azure, Microsoft 365)
• SaaS platform infrastructure (Entiros-hosted)
• Applications (internal and customer-facing)
• Network devices and equipment
• Endpoints (laptops, desktops, mobile devices)
• Operating systems and software
• Development, testing, and production environments
• Third-party services and integrations

Vulnerability types in scope:

• Operating system vulnerabilities
• Application vulnerabilities
• Configuration weaknesses
• Missing security patches
• Outdated software versions
• Network vulnerabilities
• Web application vulnerabilities
• Cloud misconfigurations

3. Definitions

Term	Definition
Vulnerability	Weakness in a system, application, or process that could be exploited to compromise security
CVE	Common Vulnerabilities and Exposures; standardized identifier for known vulnerabilities
CVSS	Common Vulnerability Scoring System; standard for assessing vulnerability severity (0-10 scale)
Patch	Software update to fix vulnerabilities or bugs
Remediation	Action to eliminate or mitigate a vulnerability
Compensating Control	Alternative security measure when direct remediation is not feasible
Zero-Day	Vulnerability with no patch available; exploited before vendor aware or patch released
Exploit	Code or technique that takes advantage of a vulnerability
False Positive	Vulnerability incorrectly identified by scanning tool

4. Responsibilities

Role	Responsibility
CISO	Overall vulnerability management program, risk acceptance decisions, escalation for critical issues
IT Operations	Vulnerability scanning, patch deployment, remediation execution, tool maintenance
System Owners	Prioritizing remediation for their systems, approving patches, testing in their environments
Development Team	Application vulnerability remediation, secure coding, code review
Network Team	Network device patching, firewall updates, infrastructure vulnerability management
Cloud Administrators	Cloud service configuration, Azure/M365 vulnerability management
All Staff	Reporting suspected vulnerabilities, applying endpoint patches promptly

5. Vulnerability Identification

5.1 Vulnerability Sources

Automated Scanning:

• Network vulnerability scanners (weekly)
• Web application scanners (monthly for external apps, quarterly for internal)
• Cloud configuration scanners (Azure Security Center, daily)
• Container vulnerability scanning (on build and registry scan)
• Endpoint detection and response (EDR) tools (continuous)
• Software composition analysis for open source (on build)

Manual Sources:

• Penetration testing (annually)
• Security assessments and audits
• Code reviews
• Vendor security advisories
• Security research and threat intelligence
• Incident investigations
• Bug bounty program (if applicable)
• User reports

Monitoring:

• NIST National Vulnerability Database (NVD)
• CISA Known Exploited Vulnerabilities Catalog
• Microsoft Security Response Center
• Vendor security bulletins
• Security mailing lists and feeds

5.2 Vulnerability Scanning Schedule

Asset Type	Scan Frequency	Tool/Method	Scope
Network infrastructure	Weekly	Vulnerability scanner	All network-accessible systems
Servers (production)	Weekly	Vulnerability scanner + agent-based	All production servers
Servers (non-prod)	Monthly	Vulnerability scanner	Dev/test environments
Endpoints	Daily (agent-based)	Endpoint management tool	All laptops, desktops
Web applications (external)	Monthly	Web app scanner + manual	Customer-facing applications
Web applications (internal)	Quarterly	Web app scanner	Internal applications
Cloud infrastructure	Daily	Azure Security Center, config scanner	All Azure resources
Containers	On build + weekly	Container scanner	All container images
Mobile applications	Quarterly + on release	SAST/DAST tools	Mobile apps

Scanning Windows:

• Production scans: Outside business hours (after 18:00, weekends)
• Non-production: Anytime during weekdays
• Critical systems: Coordinate with system owner

Authenticated Scans:

• Preferred for deeper vulnerability detection
• Use dedicated scanning accounts with read-only access
• Credentials stored securely, rotated regularly

5.3 Vulnerability Discovery Reporting

Internal Discovery:

• Staff who discover vulnerabilities report to security@swedwise.se or CISO
• Include: System affected, description, potential impact, evidence
• CISO logs in vulnerability tracking system

External Disclosure (Responsible Disclosure):

• Security researchers report to security@swedwise.se
• Acknowledge receipt within 24 hours
• Assess and respond per disclosure policy
• Coordinate patch/fix and disclosure timeline
• Thank researcher (credit if appropriate)

6. Vulnerability Assessment and Prioritization

6.1 Severity Classification

Use CVSS score as baseline, adjust based on context:

Severity	CVSS Score	Remediation Timeline	Examples
Critical	9.0 - 10.0	7 days	Remote code execution, authentication bypass, actively exploited
High	7.0 - 8.9	30 days	Privilege escalation, sensitive data exposure, SQL injection
Medium	4.0 - 6.9	90 days	Cross-site scripting, denial of service, information disclosure
Low	0.1 - 3.9	180 days or next cycle	Minor information leaks, low-impact configuration issues

6.2 Contextual Risk Factors

Adjust severity based on:

Increase Severity If:

• System is internet-facing or customer-facing
• System processes Restricted or Confidential data
• Exploit code is publicly available
• Vulnerability is being actively exploited in the wild
• System is SaaS production platform
• No compensating controls in place
• Affects authentication or authorization

Decrease Severity If:

• Strong compensating controls exist
• System isolated from network
• Requires local access or authentication
• Low business impact
• Non-production environment
• Vendor has confirmed not exploitable in our configuration

Business Impact Considerations:

• Customer data at risk → Higher priority
• SaaS service availability impact → Higher priority
• Development/test system → Lower priority (unless leads to production)
• Compliance requirement → Higher priority

6.3 Prioritization Matrix

Prioritization = Severity + Exploitability + Asset Criticality

Priority Levels:

Priority	Criteria	Action
P1 - Emergency	Critical vulnerability + Internet-facing + Actively exploited	Patch immediately (24-48 hours), emergency change process
P2 - Urgent	Critical/High + Production system + Exploit available	Patch within timeline, expedited testing
P3 - Standard	High/Medium vulnerability + Normal business impact	Patch per standard timeline, normal testing
P4 - Low	Low vulnerability or well-mitigated	Next patch cycle or accept risk

6.4 False Positive Management

Process:

1. Verify vulnerability through manual testing or investigation
2. If confirmed false positive:
   • Document justification
   • Mark in vulnerability tracking system
   • Tune scanner to prevent recurrence if possible
3. Review false positive decisions annually

7. Patch Management

7.1 Patch Sources

Operating Systems:

• Windows: Microsoft Update / WSUS
• Linux: Distribution package managers
• macOS: Apple Software Update

Applications:

• Vendor update mechanisms
• Microsoft 365: Microsoft-managed
• Azure: Microsoft-managed (PaaS) or customer-managed (IaaS)
• Third-party applications: Vendor sites/portals

Third-Party Software:

• Monitor vendor security advisories
• Subscribe to security notification lists
• Maintain vendor contact information

7.2 Patch Testing

Testing Approach:

• Test patches in non-production environment before production deployment
• Prioritize testing based on criticality and risk
• Document test results

Testing Scope:

Severity	Testing Requirement	Approval
Critical (Emergency)	Minimal testing: Verify patch installs and service starts	CISO + System Owner
Critical/High	Standard testing: Functionality test, basic integration	System Owner
Medium/Low	Full testing: Functionality, integration, performance	System Owner or delegated

Testing Timeline:

• Emergency patches: 4-8 hours testing
• Critical/High: 1-5 days testing
• Medium/Low: 1-2 weeks testing

Test Environment:

• Staging environment representative of production
• Test on sample of system types if large fleet
• Document test results and approval

7.3 Patch Deployment Schedule

Standard Patch Windows:

System Type	Patch Window	Frequency
Endpoints (laptops/desktops)	Anytime (automated restart overnight)	Weekly (Microsoft Patch Tuesday + 5 days)
Production servers	After-hours maintenance window [TBD - e.g., 2nd Tuesday 22:00-02:00]	Monthly
SaaS platform	Scheduled maintenance window [TBD - per SLA]	As needed for critical, monthly for others
Network infrastructure	Scheduled maintenance [TBD - Quarterly]	Quarterly or as needed
Non-production systems	Anytime during business hours	As needed

Emergency Patching:

• For Critical severity with active exploitation
• Expedited approval and deployment
• May require out-of-schedule maintenance window
• Customer notification for SaaS platform (per SLA)

Deployment Phases:

1. Pilot (10% of systems): Deploy to test/canary systems, monitor 24 hours
2. Wave 1 (40%): Deploy to non-critical systems, monitor 48 hours
3. Wave 2 (50%): Deploy to remaining systems including critical systems

Rollback Plan:

• Document rollback procedure before deployment
• Keep previous version/backup available
• Monitor for issues during and after deployment
• Rollback if critical issues discovered

7.4 Patch Compliance Monitoring

Metrics:

• Percentage of systems patched within SLA
• Time to patch (from release to deployment)
• Systems with overdue patches
• Exceptions and risk acceptances

Reporting:

• Weekly: Patch status dashboard (IT Operations internal)
• Monthly: Patch compliance report to CISO
• Quarterly: Trend analysis to management

Non-Compliance:

• Identify systems missing patches
• Investigate reasons (failures, exceptions, missing systems)
• Remediate or escalate
• Report persistent non-compliance to CISO and system owner

8. Remediation

8.1 Remediation Options

Preferred Order:

1. Patch/Update: Apply vendor patch or update to fix vulnerability
2. Configuration Change: Adjust settings to eliminate or mitigate vulnerability
3. Compensating Control: Implement additional security measures to reduce risk
4. Workaround: Temporary measure until patch available
5. Risk Acceptance: Formally accept risk if remediation not feasible (requires approval)
6. Decommission: Remove system if no longer needed or too risky to maintain

8.2 Remediation Process

Step 1: Assign Remediation

• Vulnerability assigned to responsible team/person
• Priority and timeline communicated
• Track in vulnerability management system

Step 2: Plan Remediation

• Determine remediation approach
• Assess impact and dependencies
• Schedule maintenance window if needed
• Plan testing and validation
• Prepare rollback plan

Step 3: Implement Remediation

• Execute planned remediation
• Document changes made
• Follow change management procedure for significant changes

Step 4: Verify Remediation

• Rescan or retest to confirm vulnerability resolved
• Validate functionality not impacted
• Update vulnerability tracking system
• Close vulnerability ticket

Step 5: Document

• Record remediation actions
• Update system documentation if configuration changed
• Note lessons learned for future

8.3 Compensating Controls

When Direct Remediation Not Feasible:

• Vendor has not released patch
• Patch causes compatibility issues
• System cannot be taken offline for patching
• Cost or complexity too high relative to risk

Examples of Compensating Controls:

• Network segmentation to limit exposure
• Web application firewall (WAF) rules
• Intrusion detection/prevention signatures
• Enhanced monitoring and alerting
• Access restrictions (firewall rules, authentication)
• Disabling vulnerable service/feature
• Data encryption

Requirements:

• Document compensating control and effectiveness
• CISO approval required
• Regular review (at least quarterly)
• Monitor for exploits targeting vulnerability
• Remediate directly when feasible

8.4 Risk Acceptance

When Remediation and Compensating Controls Not Feasible:

Process:

1. System owner proposes risk acceptance
2. Document:
   • Vulnerability details and severity
   • Business justification for not remediating
   • Risk assessment (likelihood and impact)
   • Duration of acceptance
   • Monitoring or controls in place
3. Risk acceptance approval:
   • Medium vulnerabilities: System Owner + IT Operations Manager
   • High vulnerabilities: CISO + System Owner
   • Critical vulnerabilities: CISO + CEO (discouraged)
4. Review quarterly or when circumstances change
5. Re-evaluate when patch becomes available

Risk acceptance NOT allowed for:

• Vulnerabilities with active exploitation in the wild
• Customer-facing SaaS platform critical vulnerabilities
• Vulnerabilities exposing customer data
• Critical vulnerabilities with CVSS 9.5+ and no compensating controls

9. SaaS Platform Vulnerability Management

9.1 Enhanced Requirements

SaaS production platform:

• Classified as Critical asset
• Patching SLA: Critical vulnerabilities within 7 days
• 24/7 monitoring for exploitation attempts
• Customer notification per SLA if vulnerability impacts service
• Quarterly penetration testing
• Monthly web application scanning

9.2 Customer Communication

When to Notify Customers:

• Critical vulnerability in customer-facing service
• Maintenance window required for emergency patching
• Vulnerability resulted in service impact
• Customer data potentially exposed

Communication Process:

1. Draft customer communication (Customer Success + CISO)
2. Management approval
3. Send via established customer communication channels
4. Update service status page
5. Follow up with resolution confirmation

9.3 SaaS Patching Coordination

Coordination with Entiros (hosting provider):

• Regular patching schedule aligned with Entiros maintenance windows
• Emergency patching coordination for critical issues
• Verification that Entiros applies infrastructure patches per SLA
• Quarterly review of Entiros patching compliance

10. Third-Party and Supply Chain Vulnerabilities

10.1 Third-Party Software Monitoring

Responsibilities:

• Track all third-party software and versions in Asset Register
• Subscribe to vendor security advisories
• Monitor for vulnerabilities in third-party components
• Assess impact of third-party vulnerabilities

Process:

1. Vendor announces security update
2. Assess applicability to Swedwise systems
3. Prioritize and schedule update
4. Test and deploy per patch management process
5. Document completion

10.2 Open Source Component Management

Software Composition Analysis (SCA):

• Scan applications for open source libraries
• Identify known vulnerabilities (CVE database)
• Maintain Software Bill of Materials (SBOM)
• Regular scanning (on build + monthly)

Remediation:

• Update to patched library version
• Replace with secure alternative if no patch
• Apply vendor patch if library embedded in commercial product
• Evaluate whether component still needed

10.3 Cloud Service Provider Vulnerabilities

Azure and Microsoft 365:

• Microsoft manages infrastructure patching
• Swedwise monitors Microsoft security bulletins
• Apply configuration changes if recommended
• Review Azure Security Center recommendations weekly

Entiros (SaaS Hosting):

• Entiros responsible for infrastructure patching per contract
• Swedwise monitors Entiros security notifications
• Quarterly review of Entiros security compliance
• Escalate concerns to Entiros management

Shared Responsibility:

• Understand shared responsibility model
• Swedwise manages: VMs, applications, data, access
• Provider manages: Physical infrastructure, hypervisor, network (varies by service model)

11. Zero-Day and Emergency Response

11.1 Zero-Day Vulnerabilities

Definition: Vulnerability with no patch available, possibly being exploited

Response:

1. Immediate Assessment (within 4 hours)

   • Determine if Swedwise systems affected
   • Assess exploitability and impact
   • Identify exposure (internet-facing, customer impact)

2. Interim Protection (within 24 hours)

   • Implement compensating controls:
     • Block exploits at firewall/WAF
     • Disable vulnerable feature/service if possible
     • Enhanced monitoring for exploitation attempts
     • Network segmentation
   • Document actions taken

3. Continuous Monitoring

   • Monitor for exploit activity
   • Watch for vendor patch announcement
   • Update threat intelligence

4. Patch When Available

   • Test and deploy immediately upon release
   • Verify compensating controls can be removed
   • Document and close incident

11.2 Widespread Critical Vulnerabilities

Examples: WannaCry, Log4Shell, Exchange ProxyLogon

Emergency Response Process:

1. Activate Incident Response

   • Assemble response team (CISO, IT Ops, System Owners)
   • Dedicated communication channel

2. Rapid Assessment (within 2 hours)

   • Inventory potentially affected systems
   • Determine actual vulnerability (versions, configurations)
   • Assess customer impact

3. Emergency Patching

   • Expedited testing (minimal viable testing)
   • Deploy patches to critical systems first
   • May require off-hours or weekend work
   • Customer notification if SaaS impact

4. Verification

   • Scan to confirm systems patched
   • Monitor for exploitation attempts
   • Incident investigation if any compromise suspected

5. Post-Event Review

   • Lessons learned
   • Process improvements
   • Update procedures

12. Vulnerability Disclosure and Communication

12.1 Internal Communication

Regular Communication:

• Monthly vulnerability summary to CISO
• Quarterly vulnerability metrics to management
• Critical vulnerabilities escalated immediately

Stakeholder Updates:

• System owners notified of vulnerabilities in their systems
• Users notified if action required (e.g., apply endpoint patches)
• Management briefed on trends and major issues

12.2 External Disclosure

Responsible Disclosure Policy:

• Published on Swedwise website [TBD - security.txt or /security]
• Contact: security@swedwise.se
• Response timeline commitment
• Coordinated disclosure process

Customer Disclosure:

• Notify customers if vulnerability affected SaaS service
• Transparency about impact and remediation
• Follow contractual notification requirements

Regulatory Reporting:

• Report security vulnerabilities per GDPR if data breach
• Coordinate with legal/privacy officer
• Follow incident management procedure

13. Vulnerability Exception Process

13.1 When Exceptions Needed

• Patch conflicts with critical application
• Vendor has not released compatible patch
• Business-critical system cannot be patched during remediation window
• Remediation cost/impact exceeds risk
• System planned for decommissioning (short-term exception)

13.2 Exception Request Process

1. Submit Exception Request

   • System owner submits to CISO
   • Include: Vulnerability details, justification, duration, compensating controls

2. Risk Assessment

   • CISO reviews risk
   • Evaluates compensating controls
   • Determines if acceptable

3. Approval

   • Medium: CISO approval
   • High: CISO + Management
   • Critical: CEO approval required

4. Document and Track

   • Exception recorded in vulnerability tracking system
   • Expiration date set (maximum 6 months)
   • Calendar reminder for review

5. Regular Review

   • Monthly review of all exceptions
   • Reassess if circumstances change
   • Remediate or renew exception

14. Tools and Technology

Vulnerability Management Tools:

• Vulnerability scanner [TBD - Vendor/product]
• Patch management system [TBD - WSUS, SCCM, Intune, etc.]
• Azure Security Center / Microsoft Defender for Cloud
• Web application scanner [TBD - Vendor/product]
• Container vulnerability scanner [TBD - Vendor/product]
• Software composition analysis [TBD - Vendor/product]
• Vulnerability tracking system [TBD - Integrated with ticketing]

Tool Requirements:

• Centralized dashboard and reporting
• Integration with asset inventory
• Automated scanning and scheduling
• Risk-based prioritization
• Compliance reporting
• API access for automation

15. Metrics and Reporting

15.1 Key Performance Indicators

Metric	Target	Measurement Frequency
Critical vulnerabilities open	0	Daily
High vulnerabilities remediated within 30 days	> 95%	Monthly
Medium vulnerabilities remediated within 90 days	> 90%	Quarterly
Mean time to remediate (MTTR) - Critical	< 7 days	Monthly
Mean time to remediate (MTTR) - High	< 30 days	Monthly
Systems scanned on schedule	> 98%	Weekly
Patch compliance (endpoints)	> 95%	Weekly
Patch compliance (servers)	> 98%	Monthly

15.2 Reporting

Weekly (IT Operations Internal):

• New vulnerabilities discovered
• Remediation progress
• Overdue remediations
• Scanning coverage

Monthly (to CISO):

• Vulnerability summary by severity
• Remediation metrics (MTTR, SLA compliance)
• Exception status
• Trend analysis

Quarterly (to Management):

• Vulnerability program effectiveness
• Major vulnerabilities and remediations
• Compliance with policy
• Improvements and recommendations

Annual (to Management/Board):

• Comprehensive vulnerability management report
• Risk trends
• Comparison to industry benchmarks
• Program maturity and improvements

16. Continuous Improvement

16.1 Program Reviews

Quarterly Reviews:

• Vulnerability trends and patterns
• Recurring vulnerabilities (root cause analysis)
• Process effectiveness
• Tool performance

Annual Reviews:

• Full procedure review and update
• Technology refresh evaluation
• Benchmark against industry standards
• Training needs assessment

16.2 Lessons Learned

After Major Vulnerabilities:

• Post-remediation review
• What went well / what could improve
• Process or tool changes needed
• Update procedures and runbooks

16.3 Training

• All staff: Security awareness includes vulnerability reporting
• IT Operations: Quarterly vulnerability management training
• Developers: Secure coding and vulnerability remediation training
• System owners: Annual briefing on vulnerability management process

17. Inputs and Outputs

Inputs:

• Vulnerability scan results
• Security advisories and bulletins
• Penetration test findings
• Incident investigation findings
• User reports
• Threat intelligence feeds

Outputs:

• Prioritized vulnerability list
• Remediation plans and schedules
• Patch deployment records
• Vulnerability reports and metrics
• Risk acceptance documentation
• Audit evidence

18. Records

Record	Retention Period	Location
Vulnerability scan results	12 months	[TBD - Vulnerability management system]
Remediation records	3 years	[TBD - Vulnerability management system]
Risk acceptance documentation	Duration + 3 years	[TBD - Document repository]
Patch deployment logs	12 months	[TBD - Patch management system]
Exception records	Duration + 2 years	[TBD - Vulnerability tracking system]
Vulnerability reports	5 years	[TBD - Document repository]

19. Related Documents

Policies:

• SW-ISMS-POL-001: Information Security Policy
• SW-IMS-POL-001: Integrated Management System Policy

Procedures:

• SW-IMS-PRO-001: Document Control Procedure
• SW-ISMS-PRO-001: Incident Management Procedure
• SW-ISMS-PRO-006: Asset Management Procedure
• [TBD - SW-ISMS-PRO-005: Change Management Procedure]
• [TBD - SW-ISMS-PRO-008: Supplier Security Assessment Procedure]

Guidelines:

• [TBD - SW-ISMS-GUI-006: Secure Configuration Standards]
• [TBD - SW-ISMS-GUI-007: Patch Management Guidelines]

Forms:

• [TBD - SW-ISMS-FRM-010: Vulnerability Risk Acceptance Form]
• [TBD - SW-ISMS-FRM-011: Vulnerability Exception Request Form]

External:

• ISO 27001:2022 - Clause 5.7 (Threat intelligence), 5.8 (Information security in project management)
• NIST National Vulnerability Database (NVD): https://nvd.nist.gov/
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

20. Document Control

Version	Date	Author	Changes	Approved By
1.0	[TBD]	[TBD - CISO]	Initial procedure creation	[TBD - CEO]

Next Review Date: [TBD - typically 12 months from effective date]

Document Classification: Internal

Document Owner: CISO

---

This procedure is approved by Swedwise AB management and is effective from the date specified above. All staff are required to read, understand, and comply with this procedure.