> For the complete documentation index, see [llms.txt](https://docs.getuntitled.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getuntitled.ai/misc/procurement-resources/observability-and-patch-management-policy.md).

# Observability & Patch Management Policy

### 1. Purpose

Untitled, LLC ("Untitled") maintains observability, vulnerability management, and patch management practices designed to support the security, reliability, and availability of its systems and Platform Services.

This policy describes Untitled's approach to identifying, evaluating, prioritizing, and remediating software vulnerabilities, system errors, and required updates across its infrastructure, applications, and dependencies.

Untitled's observability and patch management practices are designed to reduce exposure to known vulnerabilities, support timely remediation of identified issues, and maintain the ongoing security and operational integrity of the Untitled Platform.

### 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.

### Questions

If you have questions regarding Untitled's Observability and Patch Management practices, please contac&#x74;**:** **<support@getuntitled.ai>**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.