Vulnerability Management Policy

1. Purpose & Scope

This Vulnerability Management Policy (“Policy”) defines how DataChimp Labs identifies, prioritizes, and remediates security vulnerabilities across its endpoints, cloud infrastructure, application dependencies, container images, and third-party components. It exists to ensure that known vulnerabilities affecting DataChimp Labs or customer data are addressed promptly, that end-of-life software is retired before it becomes a liability, and that DataChimp Labs’ external attack surface is continuously validated.

The Policy applies to:

All workforce endpoints (employee and contractor laptops, mobile devices used for corporate access).
All production and non-production cloud assets — server instances, containers, container images, serverless functions, databases, storage buckets, network components, and managed services.
All application dependencies (open-source and commercial) shipped in DataChimp Labs software.
All third-party integrations that expose DataChimp Labs or customer data.

This Policy supplements the Information Security Policy and inherits its severity-based remediation SLAs where specific SLAs are not otherwise defined here.

2. Policy Statement

DataChimp Labs operates a continuous vulnerability management program that combines automated scanning across every layer of the stack, severity-based remediation service-level agreements, active monitoring of end-of-life software, structured third-party validation (penetration tests), and an open channel for responsible disclosure from external researchers.

3. Governance & Ownership

Role	Responsibility
Security Lead	Owns this Policy; owns the vulnerability register; owns SLA enforcement; approves exceptions.
Engineering Leadership	Owns remediation of application, dependency, container, and infrastructure findings; owns SDLC pipeline gates.
IT / People Operations	Owns workforce endpoint patching and endpoint agent coverage.
Cloud Platform Owner	Owns cloud configuration scanning, AWS Inspector coverage, and infrastructure-level remediation.
Compliance Lead	Owns coordination with external assessors, penetration testers, and responsible-disclosure researchers.
All Personnel	Apply required patches; do not disable endpoint agents; report suspected vulnerabilities without delay.

4. Definitions

Vulnerability. A weakness in a system, application, dependency, configuration, or process that, if exploited, could compromise the confidentiality, integrity, or availability of DataChimp Labs or customer data.
Severity. The rating assigned to a vulnerability based on exploitability, impact, environmental factors, and the data classification of affected assets. Baseline scores are taken from CVSS v3.1 or v4 and adjusted for environmental context.
End-of-life (EOL). A version of software, operating system, language runtime, or library that no longer receives security patches from its vendor or maintainer.

5. Severity Ratings & Patch SLAs

Vulnerabilities are rated on the following scale, and remediation is executed within the corresponding SLA measured from the time the vulnerability is confirmed in the vulnerability register:

Severity	Description	Patch SLA
Critical	Actively exploited in the wild, or trivially remotely exploitable with high impact; or affects Restricted-tier data.	7 calendar days
High	Remotely exploitable with meaningful impact; or affects Confidential-tier data; or a chain that reduces to critical.	30 calendar days
Medium	Exploitable under realistic conditions with moderate impact; or hardening finding on a production asset.	90 calendar days
Low	Limited impact, difficult to exploit, or informational; hardening findings on non-sensitive assets.	Next scheduled patch cycle

Note: this table governs patch application for identified vulnerabilities. Broader risk-remediation SLAs are defined in the Information Security Policy §4.3 and measure a distinct control.

Emergency (zero-day) escalation. For actively exploited zero-day vulnerabilities affecting production assets, the Security Lead may compress the Critical SLA to as short as 24 hours to mitigation and apply compensating controls (WAF rules, egress blocks, workload isolation) while a permanent fix is prepared. Emergency escalations are documented in the incident register alongside the vulnerability register.

SLA start. The SLA clock starts when the vulnerability is confirmed (triage complete, affected assets identified). Where DataChimp Labs learns of a vulnerability before its details are publicly known, the SLA clock starts at the earlier of confirmation or the moment the vulnerability is added to the register.

Exceptions. Any deviation from these SLAs requires a documented risk acceptance signed by the Security Lead (and, for Critical / High items, the CTO), a compensating control, and a defined expiration date, tracked in the risk register.

6. Employee & Contractor Endpoints

DataChimp Labs continuously scans workforce endpoints for vulnerabilities and enforces baseline posture:

Mobile Device Management (MDM). All workforce endpoints — laptops and mobile devices used for corporate access — are enrolled in the corporate MDM. Enrollment enforces full-disk encryption, screen lock, automatic OS updates, password / passcode policy, and remote wipe.
Endpoint protection agent. Every workforce endpoint runs an endpoint detection and response (EDR) / anti-malware agent that performs continuous scanning for malware, misconfigurations, and known-vulnerable software installations.
Vulnerability scanning against endpoints. The MDM and EDR platforms jointly produce an inventory of installed software with version data; this inventory is cross-referenced against vulnerability feeds so that vulnerable versions on endpoints appear in the vulnerability register and are patched per the SLAs in Section 5.
Patch management. Operating system, browser, and productivity software patches are pushed automatically. Deferrals are bounded and visible to Security.
Non-compliant devices. Endpoints that lose posture (encryption disabled, agent uninstalled, OS out of support) are automatically restricted from accessing production and Confidential / Restricted resources through conditional access.

7. Production Assets — Continuous Scanning

DataChimp Labs runs continuous vulnerability scans against production assets across every layer of the stack.

7.1 Cloud Infrastructure

AWS Inspector (or equivalent cloud-native service) is enabled across production accounts and continuously scans EC2 instances, container images in ECR, and Lambda functions for known CVEs and network-reachable vulnerabilities.
Cloud configuration scanning. AWS Security Hub, AWS Config rules, and a cloud security posture management (CSPM) capability continuously evaluate account configuration against CIS Benchmarks and internal baselines. Findings feed the vulnerability register.
Server instances. Long-lived instances are minimized in favor of immutable, short-lived compute; where long-lived instances exist, they are covered by Inspector and the internal patching cadence.
Managed services. Managed database and analytics services follow their vendor’s automatic patching cadence; DataChimp Labs opts in to the vendor’s automated minor-version upgrades and reviews major-version upgrades on a documented cadence.

7.2 Containers & Images

Base image discipline. Container images are built from a small set of approved, minimal base images that are refreshed on the base image’s own security schedule.
Image scanning in CI/CD. Every image built in the CI/CD pipeline is scanned for known CVEs, misconfigurations, and secret leakage. Findings above the configured severity threshold block the pipeline and require remediation before promotion.
Registry scanning. Amazon ECR (or the equivalent registry) is configured for continuous scanning of stored images so that images which passed at build time but became vulnerable due to newly disclosed CVEs are surfaced.
Runtime image drift. Production runtimes are prohibited from running images that are not present in the approved registry, and image tags are pinned to digests to prevent silent upgrades.

7.3 Application Dependencies (SCA)

Software Composition Analysis (SCA). Every pipeline execution runs SCA against declared dependencies (npm, PyPI, Maven, Go modules, Cargo, etc.). Findings above the severity threshold block merges and deployments.
Lockfile hygiene. Dependency lockfiles are required for all services; unpinned or floating dependencies are prohibited in production code paths.
Automated dependency updates. Dependencies are updated on an automated cadence, with security-only updates promoted expeditiously and non-security updates batched.
Transitive dependencies. SCA covers transitive dependencies; a transitive vulnerability that has no fixed version yet is triaged with compensating controls (usage-based analysis, feature disablement, isolation) until a fix is available.

7.4 Static Analysis & Secret Scanning

Static Application Security Testing (SAST). SAST tools run on every pipeline execution and against every pull request. Findings above the severity threshold block merges.
Secret scanning. Repositories and pipelines are scanned for committed secrets in real time. Detected secrets trigger automatic rotation, revocation of the compromised credential, and incident handling.

8. End-of-Life (EOL) Software

End-of-life software is a specific, actively managed risk category:

EOL inventory. DataChimp Labs maintains an inventory of the supported-until dates for the operating systems, language runtimes, major libraries, container base images, database engines, and vendor products in use. The inventory is refreshed continuously from authoritative vendor sources.
Active monitoring. End-of-life and end-of-support dates for platform components are tracked in the platform-lifecycle backlog, with per-component migration dates recorded and reviewed at each quarterly platform review. Components entering the final 90 days of vendor support are escalated to the Security Lead for migration scheduling. Assets past EOL are treated as High-severity findings and remediated per the Section 5 SLA (30 calendar days), unless a documented exception with a compensating control is on file.
Remediation options. Migration to a supported version is the default. Where migration is not feasible in the SLA, options include extended vendor support (paid), workload retirement, or network isolation with compensating controls.
No new deployments on EOL. New production deployments are prohibited from running EOL software. Pipeline checks block provisioning of prohibited base images and runtimes.

9. Penetration Testing

Cadence. DataChimp Labs engages a qualified independent third-party firm to conduct penetration tests at least annually and on every material change to the platform, product, or attack surface. Examples of material changes include a new customer-facing product, a significant architectural change to authentication or data handling, onboarding a new regulated data class, or a merger / acquisition.
Scope. Tests cover external network / web application surfaces, authentication and authorization flows, mobile applications where applicable, and cloud configuration. Internal (assumed-breach) tests are performed on a defined cadence.
Findings. Findings are triaged into the vulnerability register with the same severity ratings and SLAs as internal findings. Executive summaries and, on request under NDA, redacted detail reports, are shared with customers whose contracts require it.

10. Bug Bounty & Responsible Disclosure

DataChimp Labs maintains an open channel for external security researchers to report suspected vulnerabilities:

Responsible disclosure channel. Researchers may email security@datachimplabs.com with reports. A public disclosure policy defines scope, safe-harbor terms, and expected response times.
Acknowledgment. New reports receive acknowledgment within 2 business days, and a triage decision within 5 business days.
Remediation. Confirmed reports are entered into the vulnerability register with the same severity ratings and SLAs as internal findings.
Bug bounty. DataChimp Labs operates its own responsible-disclosure and bug bounty program on the DataChimp Labs platform. Scope, rewards, and rules are published as part of the disclosure policy. Reports and submissions are directed to security@datachimplabs.com.
No legal action for good-faith research. DataChimp Labs will not pursue legal action against researchers who follow the disclosure policy in good faith, do not access data beyond what is necessary to demonstrate the vulnerability, and do not degrade the service.

11. Vulnerability Register & Reporting

Register. Every confirmed vulnerability is captured in the vulnerability register with: source (scanner, tester, disclosure), affected assets, severity, SLA due date, owner, remediation plan, and status.
Correlation. Findings from multiple sources (SCA, SAST, Inspector, Security Hub, penetration tests, disclosures) are correlated on affected asset so that a single underlying issue is not counted many times.
Metrics. Program metrics — coverage, mean time to remediate (MTTR) by severity, SLA attainment, EOL exposure — are tracked and reviewed by the Security Steering group at each quarterly meeting.
Reporting. Customers with contractual reporting rights receive summary reports of open findings affecting their data on the cadence specified in their contract.

12. Exceptions

Any deviation from this Policy — for example, a deferred patch that would break a critical customer integration — requires a documented risk acceptance signed by the Security Lead (and, for Critical / High items, the CTO), a compensating control, and a defined expiration date. Exceptions are tracked in the risk register and reviewed at each Security Steering group meeting.

13. Review Cadence

This Policy is reviewed by the Security Lead at least annually and whenever there is a material change to the vulnerability tooling stack, the platform, the regulatory landscape, or the organization. The next scheduled review date is recorded in the front-matter of this document.

14. Enforcement

Compliance with this Policy is a condition of employment or engagement with DataChimp Labs. Attempted circumvention of scanning controls (for example, disabling endpoint agents, suppressing pipeline findings without an approved exception, or running EOL software on production without an approved exception) may result in disciplinary action up to and including termination, and, where appropriate, referral to law enforcement.

15. Approval & Version History

Version	Date	Author	Change
1.0	2026-09-01	DataChimp Labs — Security	Initial issue of the Vulnerability Management Policy.

Approved by: CTO, DataChimp Labs (signature on file with the Security Lead).

Contact. Security disclosures and questions about this Policy should be directed to security@datachimplabs.com. Postal correspondence: DataChimp Labs, 4507 N 189th St, Elkhorn, NE 68022, USA.