Incident Response Policy

Effective Date: May 8, 2026 · Last Updated: May 8, 2026 · Version 1.0

1. Purpose

This page describes the customer-facing commitments of Veri-Tech's incident response program. It summarizes how Veri-Tech detects, classifies, contains, and communicates security incidents that affect Veri-Tech systems, Customer Data, or any event that may constitute a Breach of Unsecured Protected Health Information under 45 CFR §164.402.

Veri-Tech maintains a written internal Incident Response Plan that governs the operational mechanics of incident handling. The internal plan is reviewed at least annually, after every Severity-0 or Severity-1 incident, and after every product change that adds new attack surface. Customers may request a summary of Veri-Tech's incident response posture for their vendor risk assessments by contacting security@veri-tech.net.

2. Scope

This policy governs Veri-Tech's response to incidents affecting:

• Veri-Tech-managed cloud infrastructure (Azure subscription, resource groups, storage, key vaults);
• Veri-Tech application registrations and service principals used to access Customer tenants;
• The customer-facing portal (veri-tech.net) and API (api.veri-tech.net);
• Sub-processor data flows that handle Customer Data (see Sub-Processors);
• Veri-Tech privileged accounts and authentication systems.

Out of scope: Customer Microsoft 365 tenants themselves. Customer is responsible for incidents that originate in or affect only Customer's tenant. For HIPAA Customers, Veri-Tech cooperates with Customer's investigation per BAA §3(c).

3. Severity Classification

Veri-Tech classifies incidents into four severity tiers, each with a defined initial response Service-Level Objective. Severity may be upgraded mid-incident; when in doubt, Veri-Tech defaults to the higher severity.

4. Response Phases

Every incident progresses through the following phases:

1. Detection. Confirm the signal is real, open an incident record, assign initial severity, and notify the Incident Commander.
2. Triage. Establish what is known versus unknown, identify affected systems, accounts, and data classes, and decide containment posture.
3. Containment. Disable compromised credentials, quarantine affected resources, roll back deployments, or take other actions to stop active harm. Forensic state is preserved before any destructive action.
4. Eradication. Identify root cause, remove attacker artifacts, patch the underlying vulnerability, and validate no lingering compromise.
5. Recovery. Restore service from a clean state, increase monitoring on affected surfaces for at least thirty (30) days, and verify Customer-facing functionality.
6. Breach Assessment. For any incident that involved actual or potential access to PHI, Veri-Tech performs the four-factor analysis required by 45 CFR §164.402 to determine whether a Breach of Unsecured PHI is presumed.
7. Notification. Notifications to affected Customers are issued in accordance with the Breach Notification Policy, the DPA, and (where applicable) the BAA.
8. Post-Incident Review. Within fourteen (14) days of closure, Veri-Tech authors a post-incident review covering timeline, root cause, lessons learned, and action items with owners and deadlines. A follow-up review at thirty (30) days verifies action items shipped.

5. Detection Sources

Veri-Tech detects incidents through:

• Continuous monitoring and alerting on the Production Service infrastructure (Azure Monitor / Application Insights);
• Microsoft Entra ID risk signals (risky sign-in detection, leaked-credential detection, atypical-travel);
• Audit log review and anomaly detection on the Veri-Tech production tenant;
• Customer reports to support@veri-tech.net or security@veri-tech.net;
• Sub-processor security advisories (Microsoft Service Health, Vercel status, Anthropic security bulletins);
• External notifications, including responsible-disclosure reports and threat-intel feeds.

6. Customer Communication During Incidents

6.1 Status Updates. During SEV-0 and SEV-1 incidents, Veri-Tech publishes status updates at least every four (4) hours to the public status page and the incident record. SEV-2 and SEV-3 incidents receive daily updates.

6.2 Customer Notification. Notifications of security incidents involving Customer Data are issued in accordance with the Breach Notification Policy, which specifies the timing, content, and method of communication required under HIPAA, GDPR, U.S. state notification laws, and Veri-Tech's contractual commitments.

6.3 Single Point of Contact. Customers receive incident communication from a designated Communications Lead. For Customers with the HIPAA Compliance Pack, the Communications Lead also coordinates with Customer's Privacy Officer or designated successor.

7. Roles

• Incident Commander — accountable for severity assignment, containment posture, and final go/no-go decisions.
• Technical Lead — executes containment, eradication, and recovery actions.
• Communications Lead — manages Customer, sub-processor, and (where required) regulator and media communication.
• Designated Signer Backup — authority to act on Veri-Tech's behalf if the Incident Commander is unavailable for more than seven (7) days.

8. Tabletop Exercises and Plan Maintenance

Veri-Tech tests this incident response program through:

• An annual full tabletop exercise covering the four-factor analysis and Customer-notification mechanics;
• Quarterly micro-tabletop exercises injecting a single scenario for focused practice;
• A post-incident plan review after every Severity-0 or Severity-1 incident, even if no formal change is made, with the decision logged.

Customers may request a summary of the most recent tabletop outcome (timeline, scenario, lessons learned) for their vendor risk assessments by contacting security@veri-tech.net.

9. Sub-Processor Cascade

If an incident involves a sub-processor, Veri-Tech cooperates with the sub-processor's incident response and considers whether Customers require notification even if no Customer Data was confirmed accessed. The current sub-processor list, with HIPAA Business Associate status, is maintained at veri-tech.net/legal/subprocessors.

10. HHS Secretary Notification

For incidents involving Protected Health Information, the Covered Entity (Customer) is responsible for any required HHS Secretary notification under 45 CFR §164.408. Veri-Tech provides the data Customer needs for that notification per BAA §3(c) and cooperates with Customer's individual-notification analysis under 45 CFR §164.404.

Contact Information

Report a security incident: security@veri-tech.net
Customer support: support@veri-tech.net
Privacy: privacy@veri-tech.net
Legal: legal@veri-tech.net