# Observability & Patch Management Policy

### 1. Purpose

The purpose of this policy is to define Untitled’s approach to identifying, evaluating, and remediating errors, vulnerabilities and applying software patches across its infrastructure and systems.

This policy is intended to ensure that updates are applied in a timely and consistent manner to reduce exposure to known vulnerabilities.

***

### 2. Scope

This policy applies to:

* Production infrastructure and systems
* Cloud resources and services (AWS)
* Application dependencies and libraries
* Internal systems and supporting services used in platform operations

***

### 3. Patch Management Approach

Untitled follows a risk-based patch management approach, prioritizing remediation based on the severity and potential impact of identified vulnerabilities.

Where possible, Untitled leverages managed cloud services to reduce direct infrastructure patching requirements, relying on AWS-managed controls for underlying system updates.

***

### 4. Vulnerability Identification

Untitled identifies vulnerabilities through a combination of:

* Automated vulnerability scanning tools (AWS, Sentry, and auxiliary dependency monitoring tools)
* Monitoring of publicly disclosed vulnerabilities (e.g., CVEs)
* Alerts from infrastructure providers and software vendors
* Internal engineering review and monitoring processes

Identified vulnerabilities are tracked and evaluated based on severity and relevance to Untitled systems.

***

### 5. SLAs, Patch Prioritization & Remediation

<table data-header-hidden="false" data-header-sticky><thead><tr><th width="187">Severity</th><th>Definition / Examples</th><th>Acknowledge within</th><th>Resolve within</th></tr></thead><tbody><tr><td>Critical</td><td>Service down / data loss</td><td>1 hour</td><td>4 hours</td></tr><tr><td>High</td><td>Major feature broken, wide user impact</td><td>4 hours</td><td>24 hours</td></tr><tr><td>Medium</td><td>Partial degradation, workaround exists</td><td>24 hours</td><td>72 hours</td></tr><tr><td>Low</td><td>Minor errors, isolated impact</td><td>72 hours</td><td>2 weeks</td></tr></tbody></table>

Patches are applied based on the severity of the associated vulnerability:

* **Critical vulnerabilities**\
  Addressed as soon as practicable, with prioritization for immediate remediation.
* **High severity vulnerabilities**\
  Addressed promptly based on risk and exposure.
* **Moderate and low severity vulnerabilities**\
  Addressed as part of normal maintenance and release cycles.

#### Issue Management:

When a user or system action triggers an error, Untitled captures details such as which endpoint failed, the error type, and how many times it occurred.

Errors are grouped by HTTP method, endpoint, and error code, and **published as issues.** Each new issue triggers a notification to an internal Slack channel. Reminders are sent every 24 hours until the issue has been reviewed.

After an issue is corrected, it will be marked as resolved with a note indicating which version includes the fix. Issue fixes are shipped as patch releases, indicated by incrementing the patch version: `major.minor.patch` (e.g., `1.1.10` → `1.1.11`).

The Untitled development team holds a weekly review to ensure low-priority issues are being triaged.

Where immediate patching is not feasible, mitigating controls may be applied to reduce risk until remediation can be completed.

***

### 6. Patch Deployment

Patches and updates are deployed through controlled processes, of which include:

* Application updates via CI/CD pipelines
* Infrastructure updates via managed cloud services or deployment workflows
* Dependency updates through version-controlled code changes

All production changes follow established deployment and change management practices, including review and approval where applicable. Issues

#### Diagram of Issue Remediation Process (Example)

<figure><img src="/files/fVrx9JvGZELyqYDAQCz1" alt=""><figcaption></figcaption></figure>

***

### 7. Weekly Review Process

Untitled maintains an ongoing process to review and track issues, errors, and vulnerability patch status.

* Issues and patch status is reviewed on a **regular basis, no less than weekly**
* Open vulnerabilities are evaluated for severity, impact, and required action
* Remediation progress is tracked through internal workflows

This review process ensures continued visibility into outstanding vulnerabilities and supports timely remediation.

***

### 8. Exceptions

In cases where a patch cannot be applied within expected timeframes, the following may occur:

* Risk is evaluated and documented internally
* Temporary mitigating controls may be implemented
* Remediation is scheduled for a future release cycle

***

### 9. Roles & Responsibilities

* **Engineering Team**\
  Responsible for identifying, prioritizing, and implementing patches and updates
* **Infrastructure / DevOps**\
  Responsible for maintaining cloud infrastructure updates and monitoring system-level vulnerabilities
* **Leadership Oversight**\
  Provides oversight on prioritization and ensures appropriate resourcing for remediation

***

### 10. Policy Maintenance

This policy is reviewed periodically on a semi-annual basis and updated as necessary to reflect changes in infrastructure, tooling, or security practices.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.getuntitled.ai/misc/procurement-resources/observability-and-patch-management-policy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.