vulnerability Management Policy

Vulnerability Management Policy — Trust Centre — Compass IoT

Our commitment

We actively look for weaknesses in our own systems.

This policy applies to all Compass IoT systems, infrastructure, platform code, third-party dependencies, and vendor relationships. It applies to all employees and contractors with a role in building, operating, or securing the platform.

Scope

What this policy covers

Policy in place

This policy covers vulnerability identification and remediation across all layers of the Compass IoT environment:

Cloud infrastructure and hosting configuration on Google Cloud Platform.
Platform application code and APIs.
Third-party libraries, packages, and software dependencies.
Internal tooling and operational systems used by Compass IoT employees.
Third-party vendor systems where they hold or process Compass IoT data.

Detection

How we identify vulnerabilities

Compass IoT uses a combination of automated scanning, manual testing, and external research to maintain continuous visibility over our vulnerability exposure.

Dependency scanning — automated tooling monitors all third-party libraries and packages for known CVEs (Common Vulnerabilities and Exposures) on every build and on a continuous schedule.
Infrastructure scanning — cloud infrastructure configuration is scanned regularly for misconfigurations, exposed services, and policy violations.
Annual penetration testing — an independent third-party conducts a full penetration test of the platform at least once per year. Findings are triaged and tracked to remediation.
Code review — all code changes undergo peer review before deployment, with security considerations as an explicit part of the review checklist.
Responsible disclosure — external researchers who discover vulnerabilities can report them to us directly. We acknowledge all reports within one business day.
Threat intelligence — we monitor security advisories for technologies we use, including GCP security bulletins, vendor advisories, and relevant CVE feeds.

Classification

Vulnerability severity levels

All identified vulnerabilities are assigned a severity level using the Common Vulnerability Scoring System (CVSS) as a baseline, adjusted for context — including the exploitability of the specific vulnerability in our environment, the sensitivity of data at risk, and whether a fix is available.

Critical CVSS 9.0–10.0

Vulnerabilities that can be exploited remotely without authentication, or that provide direct access to customer data or administrative control of production systems. Requires immediate response.

Remediation target: within 48 hours of confirmed identification.

High CVSS 7.0–8.9

Vulnerabilities with significant exploitability or impact that require prompt action. May require authentication or specific conditions to exploit, but pose material risk if unaddressed.

Remediation target: within 7 days.

Medium CVSS 4.0–6.9

Vulnerabilities with limited exploitability or impact in isolation, but which should be addressed in the normal course of maintenance. May become higher severity in combination with other weaknesses.

Remediation target: within 30 days.

Low CVSS 0.1–3.9

Minor weaknesses with negligible exploitability or impact. Tracked and addressed as part of scheduled maintenance cycles rather than requiring immediate action.

Remediation target: within 90 days.

Remediation

How we remediate vulnerabilities

All confirmed vulnerabilities are tracked from identification through to remediation. No confirmed Critical or High vulnerability is left unresolved beyond its target remediation window without an explicit risk acceptance decision by the leadership team.

Step 01

Triage

Vulnerability confirmed and severity assessed using CVSS adjusted for our environment.
Exploitability in our specific configuration evaluated — a high CVSS score does not automatically mean high risk in context.
Owner assigned for tracking and remediation.
Interim mitigations identified where a full fix is not immediately available.

Step 02

Containment

For Critical and High findings, interim mitigations are applied immediately while a full fix is developed — such as WAF rules, access restrictions, or service isolation.
Affected systems are assessed for any evidence of active exploitation.
If active exploitation is confirmed, the Incident Response process is triggered.

Step 03

Fix and deployment

Fix developed, tested in staging, and deployed to production following our Change Management Policy.
For dependency vulnerabilities, the affected package is updated or replaced.
For infrastructure vulnerabilities, configuration is corrected and hardened.
Fix verified in production before the vulnerability record is closed.

Step 04

Verification and closure

Fix verified through re-scan or targeted testing to confirm the vulnerability is no longer present.
Vulnerability record closed with remediation date, fix method, and verifier documented.
Patterns identified across multiple findings are fed back into secure development practices.
Penetration test findings are re-tested at the next scheduled pentest to confirm persistent remediation.

Risk acceptance

Where a vulnerability cannot be remediated within the target window — due to dependency on a third party, architectural constraints, or business impact of the fix — a formal risk acceptance decision is required from the leadership team. Accepted risks are documented, time-limited, and reviewed at the next scheduled review cycle. Risk acceptance is never a permanent resolution.

Penetration testing

Independent security testing

Compass IoT conducts annual penetration tests carried out by an independent third-party. Penetration testing provides assurance that our controls are effective against realistic attack scenarios, not just known vulnerability patterns.

Annual penetration test covering platform APIs, authentication, infrastructure, and data access controls.
Scope defined in advance and agreed with the testing firm — covering all customer-facing and internal production systems.
All findings are triaged and tracked to remediation using the severity framework above.
Critical and High findings are remediated before the next scheduled test, or subject to a formal risk acceptance process.

External reporting

Responsible disclosure

Compass IoT operates a responsible disclosure programme for external researchers who discover potential vulnerabilities in our platform. We welcome good-faith security research and commit to responding transparently.

We will acknowledge all reports within one business day.
We will keep reporters informed of our assessment and remediation progress.
We will not take legal action against researchers who follow responsible disclosure principles — disclose privately, allow reasonable time to respond, and do not exploit the vulnerability or access customer data.
We do not currently operate a bug bounty programme, but we recognise and thank researchers who report valid findings.

Policy review

Policy ownership and review

This Vulnerability Management Policy is owned by Compass IoT's engineering leadership and reviewed annually, or following any incident where an unpatched or untracked vulnerability was a contributing factor.

Report a vulnerability

Security team

To report a suspected vulnerability, contact us directly.

trust@compassiot.com →