Safety & Compliance

DEOS Information Technology Change Management System

Company: I REVLAB, INC.
Program Owner: DEOS Engineering, with Security, Operations, Management, and Legal oversight
Document Version: 2.1
Last Updated: November 4, 2026
Review Cycle: At least annually and following material changes to technology, risks, or applicable requirements

DEOS manages changes to its platform through a documented process that connects business justification, risk assessment, independent review, testing, deployment authorization, and production validation. This process covers software, cloud infrastructure, dealership integrations, data handling, AI models, and agent behavior. Its purpose is to support reliable service and protect dealership information while allowing necessary improvements and urgent security responses to proceed under accountable controls.

Purpose And Scope

This document establishes the requirements for requesting, assessing, approving, implementing, and closing technology changes. Changes must protect confidentiality, integrity, and availability; preserve dealership separation and authorized processing boundaries; minimize avoidable disruption; and produce evidence of the decisions and actions taken.

The procedure applies to DEOS employees, contractors, and authorized service providers involved in developing, administering, or maintaining DEOS systems. Covered changes include bug fixes, feature releases, patches, upgrades, database migrations, infrastructure and network configurations, identity and access settings, integrations, deployment pipelines, AI model versions, system prompts, retrieval configurations, agent permissions, communication workflows, and emergency repairs. Third-party changes affecting DEOS are assessed and managed according to the control DEOS has over them.

This process supports the change management objectives of the AICPA Trust Services Criteria, including CC8.1, and DEOS's SOC 2 Type 1 readiness program. Secure development practices draw on the NIST Secure Software Development Framework (SSDF). These references guide control design; this procedure does not itself constitute an independent assurance report.

Table Of Contents

01. Governance And Responsibilities

Engineering owns the technical execution of this procedure. Management assigns approval authority and resources. Security reviews changes affecting security controls, sensitive information, or material exposure. Legal and privacy personnel participate when changes affect processing purposes, notices, consent, retention, contractual commitments, or regulatory obligations.

Role Responsibility
Change Requestor Documents the need, scope, affected services, and proposed outcome.
Change Owner / Implementer Develops the plan, coordinates testing, implements the approved change, and supplies evidence.
Independent Reviewer Reviews code or configuration, risk, and relevant test results independently of the change author.
Designated Approver / Change Advisory Board Authorizes changes within delegated authority; a Change Advisory Board (CAB) is used where risk or coordination warrants it.
Change Manager / Coordinating Owner Tracks the change through approval, communications, implementation, validation, and closure.
Service Owner Confirms operational readiness, acceptance criteria, and recovery arrangements for the affected service.

Roles may be combined where appropriate, but the author of a normal production change must not be its sole reviewer and approver. Access restrictions and recorded approvals support segregation of duties. Emergency departures follow Section 10.

02. Change Categories And Risk Classification

DEOS uses three change categories. Risk determines the depth of review, testing, approval, and monitoring rather than the size of a code change alone.

Category Use And Required Control
Standard Change A repeatable, low-risk activity performed within a documented, previously approved procedure. Each execution remains traceable. Changes outside the approved conditions require normal review.
Normal Change A change assessed, reviewed, tested, and authorized before production implementation. Material or high-risk changes receive additional review by the relevant control owners.
Emergency Change An expedited change needed to contain an active threat, restore critical service, or address comparable imminent harm. Authorization and evidence requirements remain applicable under the emergency process.

Risk assessment considers dealership and consumer impact, data sensitivity, tenant boundaries, privileges, reversibility, expected downtime, integration dependencies, communication volume, and changes to automated decision or action authority. A change to a suppression rule or agent permission may be high risk even when technically small. A repeated activity is not automatically a standard change.

03. Change Requests And Required Records

Changes are recorded in the approved change tracking system. Linked development, deployment, and incident records may form one traceable change record rather than duplicating the same evidence across tools.

The record must identify:

Passwords, tokens, private keys, unnecessary consumer records, and other sensitive production content must not be copied into change tickets or release notes. Evidence is restricted and minimized according to its sensitivity.

04. Evaluation And Planning

The change owner and reviewers assess whether the proposed implementation is necessary, appropriately scoped, and compatible with DEOS security requirements and customer commitments. Assessment includes the consequences of both making and deferring the change.

Planning addresses dependencies, capacity, data integrity, integration compatibility, deployment sequencing, maintenance requirements, and the ability to detect failure. Changes affecting data access, processing destinations, retention, consent, or dealership separation require explicit consideration of those boundaries before approval.

Each change requires a practicable recovery strategy. Reversible releases should have defined rollback triggers and steps. For irreversible operations, such as some database migrations, the plan must instead explain backup or restore requirements, forward recovery, reconciliation, and limitations. A rollback label alone does not establish recoverability. Plans must account for external effects, including messages already delivered or records already written to an authorized third-party system.

05. Peer Review And Source Control

Code changes receive peer or independent review before merging into protected production release branches. Review considers functionality, security, maintainability, data handling, and the scope of authorized behavior. Relevant infrastructure, configuration, and deployment changes are version controlled or otherwise captured through an approved change record.

Repository protections enforce required review and applicable automated checks on protected branches. Access to modify these protections is restricted. Changes to the protections themselves require authorization and logging; an administrator's technical ability to bypass a control is not standing permission to do so.

Reviewed artifacts must remain traceable to what is deployed. Material changes after approval require renewed review and any affected tests. AI-generated code and configuration receive the same review and testing requirements as other contributions; generation by an AI tool does not constitute approval.

06. Testing And Acceptance Criteria

Testing is proportionate to risk and performed before production deployment in an appropriate nonproduction environment. Applicable checks include functional and regression tests, security scanning, dependency checks, integration compatibility, access control, tenant isolation, migration integrity, performance, and recovery validation. Not every change requires every test, but omissions must be justified by the change's nature and risk.

Acceptance criteria are defined before deployment. Test failures and material residual risks must be resolved or explicitly accepted by authorized decision-makers within policy limits. Testing cannot authorize conduct prohibited by law, contract, or DEOS data protection requirements.

Synthetic or appropriately de-identified data is preferred for testing. Masking alone does not establish that information is anonymous. Any exceptional use of production information requires an approved purpose, restricted access, and safeguards consistent with its classification. Test environments must not send unintended communications to real consumers.

Where emergency conditions prevent normal testing, the record identifies the omitted checks, expected consequences, compensating safeguards, and follow-up validation required under Section 10.

07. Authorization And Production Access

Normal changes require authorization before production deployment. Approval confirms that the documented scope, relevant reviews, tests, recovery arrangements, and communication requirements are acceptable. Higher-risk changes require the appropriate service, security, management, or legal approvals. Standard changes rely on the documented authorization of their approved procedure and execution conditions.

Production access is limited to authorized personnel and service identities with the minimum required privileges. Human privileged access requires strong authentication, including MFA. Automated deployment identities use controlled credentials and permissions appropriate to their function. Secrets are managed through approved mechanisms rather than embedded in code or tickets.

Deployment automation may execute an approved release, but it does not remove approval requirements. Direct production changes outside the controlled deployment route require an authorized exception or emergency record, with resulting configuration reconciled into the maintained source of truth.

08. Implementation And Deployment Monitoring

The implementer confirms authorization, release identity, deployment prerequisites, and recovery readiness before execution. Maintenance windows are used where disruption or coordination requires them; a routine release does not necessarily require downtime.

Deployments follow the approved sequence. Staged releases, feature flags, limited tenant exposure, or other controlled rollout methods are used where appropriate to contain risk. Feature flags and configuration switches that materially alter production behavior are themselves subject to change control.

Monitoring examines the affected service, relevant error and security events, performance, data integrity, integration results, and customer-facing behavior. Defined failure conditions trigger a pause, rollback, or recovery action. Unexpected security or privacy effects are escalated through incident management rather than handled solely as a release defect.

09. Production Validation And Closure

Post-implementation validation confirms that acceptance criteria are met and that relevant controls continue to function. The change record captures actual timing, deployed versions or configuration, monitoring results, deviations, and any recovery actions.

Failed, emergency, material, or otherwise significant changes receive a documented post-implementation review proportionate to their impact. Routine changes may use a shorter validation record. Findings become assigned corrective actions with owners and target dates.

A change is closed only after required validation and records are complete and remaining issues are assigned or formally accepted. A successful deployment job alone is insufficient evidence of successful service behavior. Failed or rolled-back changes retain their history and are not relabeled as successful releases.

10. Emergency Changes And Exceptions

Emergency handling is limited to circumstances in which the normal timing would materially increase security, availability, or other imminent operational harm. Convenience or a missed release deadline does not justify emergency classification.

The implementer obtains approval from a designated emergency authority before execution wherever practicable. If immediate containment or restoration makes advance approval impracticable, an authorized responder may act within delegated incident authority, record the reason, and notify the appropriate decision-makers as soon as practicable. Independent retrospective review is required; it records what occurred and any control departure rather than treating later review as prior approval.

Emergency changes must include a practicable recovery approach. If rollback would be unsafe or impossible, the responder documents the containment and forward recovery strategy, dependencies, and material limitations. Expedited changes still use available testing, restricted access, and monitoring.

The change is logged before implementation where practicable, otherwise as soon as conditions permit. Outstanding tests, source control reconciliation, independent review, and corrective actions are completed promptly according to documented urgency and impact. Temporary access or workarounds are removed or regularized through normal review.

Other exceptions require a named owner, justification, risk assessment, compensating controls, authorized approval, and an expiration or review date. Exceptions cannot waive applicable law or customer contractual rights.

11. AI, Data, And Integration Changes

Changes to AI behavior are controlled even when they do not involve application code. Model versions, system prompts, retrieval sources, routing, tool permissions, action thresholds, and agent configurations must be traceable and assessed for their effect on authorized behavior.

Relevant evaluation includes incorrect or unsupported outputs, prompt injection, unauthorized tool use, sensitive information disclosure, cross-tenant retrieval, and escalation behavior. Changes to automated calls, SMS, or other outreach must preserve applicable identity disclosures, consent checks, suppression, scheduling, and opt-out handling. Safety-critical communication controls cannot be disabled simply to improve campaign performance.

Changes affecting the Dealer Data Universe (DDU), access policies, caches, search indexes, exports, or group permissions must preserve authorized dealership boundaries. Group access is granted through explicit permissions rather than an assumption that shared ownership permits unrestricted access.

Private dealership records, customer conversations, prompts, biometric information, and likeness assets must not be introduced into shared or general-purpose model training contrary to DEOS policies and agreements. A new provider, inference route, or processing purpose requires review of the data flow and applicable commitments before activation. Routine release approval does not create permission for a new use of protected information.

Integration changes must consider API scopes, credential handling, vendor requirements, schema changes, record ownership, duplicate actions, retries, and reconciliation. Deployment must not silently broaden access or transmit dealership data to a new recipient. Recovery planning must address effects that cannot be undone by reverting application code.

12. Communications And Customer Coordination

Communication begins during planning and continues through implementation and closure. Relevant internal teams receive the information needed to prepare, monitor, support, and recover affected services.

Customers are notified of material service effects, required actions, or changes to agreed processing arrangements according to applicable contracts, policies, and law. Release notes describe relevant product changes without exposing sensitive security details or private dealership information. Emergency communications reflect the urgency and available facts; necessary incident notices follow the incident response process.

Publication of release notes or a revised policy does not replace required customer authorization, individual consent, or a contractual amendment.

13. Evidence, Oversight, And Continuous Improvement

Change records, approvals, review history, test results, deployment logs, and validation evidence are retained under the applicable records retention schedule and legal hold requirements. Access is restricted, and records are protected against unauthorized alteration or deletion. Administrative access to change systems is itself controlled and logged.

Engineering and Security review change control performance through the DEOS Trust Management System. Measures include failed releases, recovery events, emergency changes, unauthorized changes, overdue reviews, and recurring defects. Findings are used to improve procedures, testing, training, and control automation.

Periodic review samples changes to assess whether approvals, independence, deployment traceability, and required testing are supported by evidence. Material deficiencies are escalated to management. Assurance materials distinguish management readiness from the scope and conclusions of any independent SOC examination.

This procedure operates alongside the DEOS Security And Technology Policies, Trust Management System, AI Governance Policy, Dealership Data Safeguards, TCPA Compliance And Acceptable Use Policy, Privacy Policy, and applicable customer agreements. Detailed internal standards define system-specific approval authority, risk criteria, response targets, and retention requirements.

The program owner reviews this procedure at least annually and following material incidents, architectural changes, control findings, or changes in applicable requirements. Approved revisions are versioned and communicated to relevant personnel.

15. Information Security Policies Notice

This document summarizes the DEOS security policy framework and communicates requirements for the personnel and providers within its scope. It does not, by publication alone, amend a customer agreement, create a separate service-level commitment, or change contractual remedies. Security or processing obligations expressly incorporated into an Agreement remain enforceable according to that Agreement.

DEOS reviews and updates its policies to reflect operational requirements, risks, technology, and law. Material changes follow applicable governance, contractual notice, and acceptance requirements. A policy revision does not retroactively authorize prohibited processing or reduce a nonwaivable right or duty.

Security controls are designed to manage risk and protect information; they do not guarantee that every incident or vulnerability will be prevented. This notice does not exclude responsibility for Company's own breach, negligence, unlawful conduct, or other liability contrary to law or the applicable Agreement. Customers and users remain responsible for the security duties assigned to them under their agreements.

Security, privacy, governance, and diligence inquiries: legal@deos1.com
Operational support and suspected account compromise: support@deos1.com

I REVLAB, INC.
4910 Communications Ave, Suite 120
Boca Raton, FL 33431