Overview
InContext Solutions maintains a proactive vulnerability management program to systematically identify, classify, remediate, and mitigate security weaknesses across our technology environment. This policy establishes a structured approach to reducing the organization's attack surface, ensuring that vulnerabilities are discovered early and addressed before they can be exploited by threat actors.
Our commitment is to continuously improve the security posture of our systems, protect customer data, and maintain the trust our clients place in us by operating a mature, metrics-driven vulnerability management lifecycle.
Scope
This policy applies to all technology assets owned, operated, or managed by InContext Solutions, including:
- All internet-facing systems and services, including web applications, APIs, and public-facing infrastructure
- Internal network infrastructure, servers, workstations, and endpoints
- Cloud resources across all environments (production, staging, development)
- Custom-developed applications and their supporting platforms
- Third-party integrations and externally hosted services that process InContext data
- Development, testing, and build environments
- Mobile applications and associated backend services
- Network devices, firewalls, load balancers, and other infrastructure components
All employees, contractors, and third-party vendors who develop, maintain, or operate systems within InContext Solutions' environment are responsible for adhering to this policy.
Vulnerability Scanning
Scanning Frequency
- External-facing systems: Automated vulnerability scans are conducted on a weekly basis against all internet-facing assets, including web applications, APIs, and perimeter infrastructure.
- Internal infrastructure: Automated scans are performed on a monthly basis across internal networks, servers, endpoints, and cloud environments.
- Ad-hoc scans: Additional scans are conducted following significant infrastructure changes, new deployments, or when a critical vulnerability advisory is published that may affect InContext systems.
Scanning Approach
- Both authenticated and unauthenticated scans are performed. Authenticated scans provide deeper visibility into system configurations and installed software, while unauthenticated scans simulate the perspective of an external attacker.
- Scanning tools must meet industry-recognized standards and maintain up-to-date vulnerability databases. Tool selection is reviewed annually by the InfoSec Team.
- Scan configurations are reviewed periodically to ensure adequate coverage across all asset types and network segments.
Triage and Review
- Scan results are reviewed by the InfoSec Team within 3 business days of scan completion.
- Findings are validated to eliminate false positives and duplicated entries before being assigned for remediation.
- Each confirmed vulnerability is classified according to the Vulnerability Classification framework defined below and assigned to the responsible asset owner for remediation.
Penetration Testing
- Annual penetration testing is conducted by a qualified, independent third-party firm with recognized industry certifications (e.g., CREST, OSCP, or equivalent).
- Testing scope includes both external and internal attack surfaces, covering network infrastructure, web applications, and cloud environments.
- Web application testing follows the OWASP Top 10 methodology to evaluate resistance against the most prevalent application-level attack vectors.
- Identified vulnerabilities are remediated according to the timelines defined in this policy, and retesting is performed by the penetration testing firm to verify successful remediation.
- An executive summary of penetration testing results, including remediation status, is shared with senior leadership and relevant stakeholders. Detailed findings are restricted to the InfoSec Team and responsible system owners.
Vulnerability Classification
Vulnerabilities are classified using the Common Vulnerability Scoring System (CVSS) to provide a standardized severity rating:
| Severity | CVSS Score | Description |
|---|---|---|
| Critical | 9.0 -- 10.0 | Vulnerabilities that can be exploited remotely with little or no user interaction, potentially leading to full system compromise, data exfiltration, or widespread service disruption. |
| High | 7.0 -- 8.9 | Vulnerabilities that pose significant risk and may allow unauthorized access, privilege escalation, or substantial data exposure. |
| Medium | 4.0 -- 6.9 | Vulnerabilities that require specific conditions or user interaction to exploit, with moderate potential impact. |
| Low | 0.1 -- 3.9 | Vulnerabilities with limited exploitability or minimal impact, typically requiring local access or unlikely attack conditions. |
| Informational | N/A | Findings that represent best-practice recommendations or hardening opportunities but do not pose a direct security risk. |
Context-Adjusted Risk
The raw CVSS score is supplemented with a context-adjusted risk assessment that considers:
- Asset criticality: Whether the affected system processes sensitive data, supports critical business operations, or is customer-facing.
- Exploitability: Whether a public exploit exists, whether the vulnerability is being actively exploited in the wild, and the complexity of exploitation.
- Compensating controls: Whether existing security controls (e.g., network segmentation, WAF rules, access restrictions) reduce the effective risk.
This contextual assessment may elevate or reduce the effective priority of a vulnerability relative to its base CVSS score.
Remediation Timelines
The following remediation timelines are mandatory. Failure to meet these timelines without an approved exception constitutes a policy violation and must be escalated to the InfoSec Team immediately.
| Severity | Remediation Timeline | Notes |
|---|---|---|
| Critical | 24 -- 48 hours | Emergency patching procedures apply. Affected systems may be isolated or taken offline pending remediation. |
| High | 7 calendar days | Expedited patching and configuration changes. Progress must be reported to the InfoSec Team within 48 hours. |
| Medium | 30 calendar days | Standard remediation through the change management process. |
| Low | 90 calendar days or next scheduled maintenance window | May be addressed during routine patching cycles. |
- When a remediation timeline cannot be met, the asset owner must document compensating controls that reduce the effective risk and obtain approval from the InfoSec Team for a time-limited exception (see Compliance and Exceptions below).
- Vulnerabilities under active exploitation in the wild are automatically elevated to Critical priority regardless of their base CVSS score.
Patch Management Integration
Vulnerability remediation is closely coordinated with the organization's Change & Patch Management process:
- Routine patches follow the standard change management workflow, including testing, approval, and scheduled deployment windows.
- Emergency patches for Critical and actively exploited vulnerabilities may bypass standard change windows under the emergency patching procedure, with post-implementation review conducted within 5 business days.
- All patches are tested in a non-production environment prior to deployment where feasible. For emergency patches where pre-deployment testing is not possible, enhanced monitoring is applied to production systems immediately following deployment.
- Rollback procedures are documented and validated before patch deployment. If a patch introduces instability or functional regression, the rollback plan is executed and the InfoSec Team is notified to identify an alternative remediation path.
Secure Development Integration
Vulnerability management is embedded into the software development lifecycle to identify and address security issues before they reach production:
- Static Application Security Testing (SAST) is integrated into the CI/CD pipeline to analyze source code for security defects during the build process.
- Dynamic Application Security Testing (DAST) is performed against staging environments to identify runtime vulnerabilities prior to production deployment.
- Software Composition Analysis (SCA) scans are executed automatically to identify known vulnerabilities in open-source and third-party dependencies.
- Developers are responsible for remediating security findings identified by SAST, DAST, and SCA tools in accordance with the remediation timelines defined in this policy.
- Security gates are enforced in the deployment process: Critical and High severity findings must be resolved or have an approved exception before code can be promoted to production.
For additional detail on secure development practices, refer to the Development Process policy.
Third-Party and Dependency Management
- Software Composition Analysis (SCA) is used to maintain a comprehensive inventory of all third-party libraries, frameworks, and components used across InContext applications.
- The InfoSec Team monitors CVE databases, vendor security advisories, and threat intelligence feeds to identify newly disclosed vulnerabilities affecting third-party components in use.
- A third-party component inventory is maintained and reviewed quarterly. Components are tracked by version, license, and known vulnerability status.
- End-of-life (EOL) software is identified proactively. When a vendor announces end-of-life or end-of-support for a component, a replacement or upgrade plan is developed and executed before support ceases. Systems running EOL software without vendor security updates are subject to enhanced monitoring and compensating controls.
Responsible Disclosure
InContext Solutions values the contributions of external security researchers who help us identify and address vulnerabilities in our systems.
Security researchers who discover a potential vulnerability in any InContext Solutions system or service are encouraged to report it responsibly by contacting security@incontextsolutions.com. Please include a detailed description of the vulnerability, steps to reproduce, and any supporting evidence such as screenshots or proof-of-concept code.
Disclosure Process
- Acknowledgment: All reports are acknowledged within 48 hours of receipt.
- Assessment: The InfoSec Team conducts an initial assessment within 5 business days to evaluate the validity and severity of the reported vulnerability.
- Communication: Reporters are kept informed of the assessment outcome and remediation progress at reasonable intervals.
- Recognition: With the reporter's consent, InContext Solutions may publicly acknowledge researchers who contribute valid findings.
Safe Harbor
InContext Solutions will not pursue legal action against individuals who:
- Make a good-faith effort to discover and report vulnerabilities in accordance with this disclosure policy.
- Avoid actions that could harm InContext Solutions, our customers, or our data, including data destruction, service disruption, or unauthorized access beyond what is necessary to demonstrate the vulnerability.
- Do not publicly disclose vulnerability details before InContext Solutions has had a reasonable opportunity to remediate the issue.
We ask that researchers refrain from accessing or modifying customer data, conducting denial-of-service testing, and social engineering InContext employees as part of their research.
Metrics and Reporting
The effectiveness of the vulnerability management program is measured through the following key metrics:
- Mean Time to Remediate (MTTR): Tracked by severity level to ensure remediation timelines are consistently met.
- Vulnerability Aging Reports: Identify vulnerabilities that have exceeded their remediation timelines, enabling escalation and corrective action.
- Scan Coverage: Percentage of assets included in regular vulnerability scanning, with a target of 100% coverage for all in-scope systems.
- Trend Analysis: Quarter-over-quarter analysis of vulnerability volume, severity distribution, and remediation performance to identify systemic issues and improvement opportunities.
Vulnerability management metrics are compiled into a monthly report for management review. Material risks, overdue remediations, and program improvement recommendations are escalated to senior leadership.
Compliance and Exceptions
Exception Process
When a vulnerability cannot be remediated within the prescribed timeline, an exception must be formally requested and approved:
- The asset owner documents the business justification for the exception, the residual risk, and any compensating controls in place.
- The InfoSec Team reviews the request and either approves or denies the exception based on the residual risk assessment.
- Approved exceptions are time-limited with a defined review date, not to exceed 90 days. Extensions require re-approval.
- Compensating controls must be documented and verified as effective for the duration of the exception.
Policy Compliance
- The InfoSec Team verifies compliance with this policy through regular audits, scan result reviews, and remediation tracking.
- Non-compliance, including missed remediation timelines without an approved exception, is escalated to management and may result in disciplinary action.
- This policy is reviewed annually and updated as necessary to reflect changes in the threat landscape, technology environment, or regulatory requirements.
Related Policies
- Change & Patch Management
- Risk Mitigation Process
- Security Incident Response Policy
- Development Process
Revision History
| Date of Change | Responsible | Summary of Change |
|---|---|---|
| April 2025 | ICS InfoSec Team | Initial publication |
| March 2026 | ICS InfoSec Team | Published to Trust Center |