AlignLayerNine® Services Guide

Copyright Notice & Restrictions on Use

This document contains proprietary, confidential, and commercially valuable information owned exclusively by AlignLayerNine, LLC (“Provider”). It is made available solely for the evaluation, negotiation, and delivery of services between Provider and the Client.

No portion of this document may be copied, reproduced, distributed, published, reverse-engineered, adapted, or used to create derivative works—whether in whole or in part—by any third party, competitor, or service provider, without the Provider’s prior written consent.

Any unauthorized use, including use by managed service providers, cybersecurity firms, consultants, or other technology service companies, is strictly prohibited and constitutes infringement of Provider’s intellectual property rights.

Client may retain a copy solely for internal business purposes related to its engagement with the Provider.

AlignLayerNine®, and any associated names, logos, service names, service marks, and branding are trademarks or registered trademarks of AlignLayerNine, LLC. All rights are reserved.

Use of the AlignLayerNine name or branding by any third party, including managed service providers, technology service companies, cybersecurity firms, consultants, or competitors, is strictly prohibited without the Provider’s prior written consent. No license or right to use any trademark of AlignLayerNine is granted by the distribution or review of this document.

Document Versioning & Interpretation Notice

This Services Guide is provided electronically and may be updated periodically to reflect changes in tools, processes, service delivery, Minimum Requirements, or operational best practices. Printed, saved, downloaded, or cached copies are not authoritative and may be outdated. The most current and controlling version of this Services Guide is the version published by the Provider on its designated website or Client Portal. Updated versions replace prior versions and govern all ongoing service delivery as of their publication date.

This Services Guide is an operational reference and does not modify, amend, or supersede the Master Services Agreement (“MSA”). In the event of any conflict between this Services Guide and the MSA, the MSA controls.

Headings, formatting styles, bolding, italics, tables, or other stylistic elements are included solely for readability and do not expand, limit, or interpret any contractual obligations. Only capitalized terms defined in Section 2 (Definitions) or elsewhere within this MSA carry contractual meaning.

This Services Guide is available at: https://alignlayernine.com/legal/services-guide

TABLE OF CONTENTS**

All capitalized terms have the meanings given in the Master Services Agreement.

1. Introduction & How to Use This Guide

1.1 Purpose of This Services Guide
1.2 Relationship to the Master Services Agreement
1.3 Scope and Nature of This Document
1.4 Overview of Service Pillars (AlignCORE, AlignSHIELD, AlignASSURE)
1.5 Intended Audience
1.6 How to Use This Guide Together With the MSA and SOWs
1.7 What this SG Does NOT Do

2. Service Model & Support Structure

2.1 Provider Support Structure (CORE Team, TAC, NOC, SOC, TAM, GRC Team)
2.2 Shared Resource Model (Team-Based Delivery; No Dedicated Personnel)
2.3 Overview of AI-Assisted Triage & Ticket Routing (High-Level)
2.4 Availability of Services (24×7×365 Support Channels)
2.5 Business Hours
2.6 Observed Holidays (U.S. Federal Holidays)
2.7 Communication Pathways
2.7.1 Client-Facing Teams (CORE Team, TAC)
2.7.2 Non-Client-Facing Teams (NOC, SOC, Upstream Vendors)
2.8 High-Level Incident and Event Flow
– Client-Generated Incidents (CORE/TAC)
– Device-Generated Events (NOC)
– Security-Generated Events (SOC)

3. Minimum Requirements, Baseline Governance & Unsupported Systems

3.1 Purpose of Minimum Requirements (Service Delivery & SLO Eligibility)
3.2 Endpoint Requirements (Tools, Compliance, Health Expectations)
3.3 Directory and Identity Requirements
3.3.1 Unique Identities (No Shared or Generic Accounts)
3.3.2 Privileged Account Governance (Client)
3.3.3 Provider Administrative Access Model
3.3.4 Supported Identity Platforms
3.3.5 Identity Security Baselines (MFA, Conditional Access, Lifecycle Controls)
3.4 Network and Infrastructure Requirements
3.4.1 UPS Requirements (Network Infrastructure and Servers)
3.4.2 Cooling & Environmental Conditions
3.4.3 Rack, Cabling & Labeling Standards (Provider Managed)
3.4.4 Commercial Hardware Requirements
3.5 Internet & Connectivity Expectations (Dual WAN / 5G Backup Recommended)
3.6 Remote Work Baseline Assumptions and Limitations
3.7 Baseline Cybersecurity Policies (Required for Clients Receiving Managed Services)
3.7.1 Written Information Security Policy
3.7.2 Termination Policy
3.7.3 Security Incident Response Policy
3.7.4 Sanction Policy
3.7.5 Network Security Policy
3.7.6 Access Controls Policy
3.7.7 Computer Use Policy
3.7.8 Disposal Procedure
3.7.9 BYOD Policy
3.7.10 Facility Security Plan
3.8 Zero Trust Baseline Requirements
3.8.1 Multi-Factor Authentication
3.8.2 Conditional Access Requirements
3.8.3 Device Compliance
3.8.4 Application Whitelisting (Default Deny)
3.8.5 Network Whitelisting (Default Deny)
3.9 Unsupported Systems
3.9.1 Definition & Examples
3.9.2 Effect on Included Services and SLOs
3.10 Risk Declination

4. Service Pillars (AlignCORE, AlignSHIELD, AlignASSURE)

4.1 AlignCORE – Managed Services
4.1.1 Overview of Included Services
4.1.2 Helpdesk & User Support
4.1.3 Endpoint & Server Management
4.1.4 Network & Infrastructure Management
4.1.5 Cloud Identity & Collaboration (Baseline Configuration)
4.2 AlignSHIELD – Security Services
4.2.1 Overview of Security Protections
4.2.2 Application and Network Whitelisting Enforcement
4.2.3 Security Monitoring (SOC Integration)
4.2.4 Vulnerability Identification & Remediation (Risk-Based; CVSS)
4.2.5 Security Incident Handling (Scope & Limitations)
4.3 AlignASSURE – Governance, Risk & Compliance Support
4.3.1 Framework Alignment (Examples)
4.3.2 Standards & Compliance Governance Lifecycle
4.3.3 Security Risk Assessments (SRA)
4.3.4 Evidence & Documentation Support (Generalized)
4.3.5 Technology Business Reviews and Strategic Planning

5. Managed vs. Co-Managed Services

5.1 Responsibilities in Managed Services
5.2 Responsibilities in Co-Managed Services
5.3 Responsibility Matrix (Provider, Client, Third-Party Providers, Upstream Vendors)
5.4 Administrative Access Governance
5.4.1 Provider Administrative Roles
5.4.2 Client Administrative Roles
5.4.3 Controls Governing Co-Managed Global Administrator Access
5.5 Change Management via Ticketing (No Side-Band Changes)
5.6 Third-Party Providers – Operational Coordination

6. Ticketing, Escalation & Change Management

6.1 Ticket Submission Channels (Portal, Email, Telephone)
6.2 Overview of AI-Assisted Triage
6.3 Business-Hours Ticket Flow (CORE Primary, TAC Overflow)
6.4 After-Hours & Holiday Ticket Flow (TAC Primary; CORE Review Next Business Day)
6.5 Severity Levels & Prioritization
6.5.1 Priority Reclassification Authority
6.6 Escalation Paths
6.7 Change Management
6.7.1 Scheduled Changes (General Principle)
6.7.2 Written Approvals from Authorized Approvers
6.7.3 Changes Requiring TAM Involvement
6.7.4 Low-Impact Changes via Ticket Response
6.7.5 Emergency Changes (Client Decision Authority; Provider Advisory Role)
6.8 Ticket Lifecycle & Closure Policy
6.8.1 One Issue per Ticket
6.8.2 Required Client Information
6.8.3 Follow-Up Attempts & Ticket Staleness
6.8.4 Automatic Closure of Inactive Tickets
6.8.5 Ticket Reopening Policy
6.8.6 Tickets Requiring Project/SOW Reclassification
6.8.7 Customer Satisfaction Feedback (CSAT)
6.8.8 SLO Applicability to the Ticket Lifecycle

7. Service Level Objectives & Reporting

7.1 SLO Response Targets
7.2 SLO Resolution Expectations
7.3 SLO Suspension Factors
7.4 Reporting & KPIs (High-Level)
7.5 Quality Assurance and Client Feedback

8. Security Operations & Incident Handling

8.1 Incident vs. Security Incident (Operational Distinctions)
8.2 Monitoring & Alert Handling (NOC & SOC)
8.3 SOC Workflow (Detect → Contain → Analyze → Notify Provider CORE Team)
8.4 Security Incident Handling (Scope & Limitations)
8.5 Vulnerability Management Overview
8.5.1 Managed Services (Signal-Based Visibility)
8.5.2 SHIELD Services (Ongoing Vulnerability Identification)
8.5.3 Risk-Based Remediation & Use of CVSS
8.5.4 Accepted Mitigations & Risk Registers
8.6 Limitations of Security Services
– No digital forensics
– No law enforcement coordination unless through a Third-Party Provider
8.7 Telemetry & Logging Requirements (High-Level)
8.7.1 Logging Retention
8.8 Client Participation in Security Incidents
8.9 Approval/Unlock Process After Blocking Actions
8.10 Application & Network Whitelisting Workflow (Operational Overview)**
8.10.1 SOC Triage (Initial Review)
8.10.2 CORE Team Review (Secondary Review)
8.10.3 Risk Declination Process (Client Decision Point)
8.10.4 Developer and Power-User Considerations
8.10.5 Planning Expectations including Presentations, Webinars, and External Meetings
8.10.6 Software Updates, In-App Updaters & Built-In Profiles

9. Cloud & Consumption Services

9.1 Cloud Identity & Tenant Governance
9.2 Cloud Resource Management (High-Level Best Practices)
9.3 Consumption Services – Billing and Behavior
9.4 Client Responsibilities for Cloud Cost Governance
9.5 Access Licensing Administration
9.5.1 Provider-Managed Licensing
9.5.2 Client-Managed Licensing
9.6 Telecom & Cloud Voice Consumption

10. Governance, Risk & Compliance (AlignASSURE)

10.1 Overview of ASSURE Services
10.2 Relationship Between Minimum Requirements and Framework-Specific Requirements
10.3 Policy & Procedure Development Workflow
– AI Output → Human Review → Client Edits → GRC Team Review → Finalization
– Client Responsible for Enforcement
10.4 Security Risk Assessments
10.4.1 Managed Services (On Request)
10.4.2 SHIELD Services (Ongoing Automated Inputs)
10.4.3 ASSURE (Human-Driven Assessments as Required by Framework)
10.5 Evidence & Documentation Support (General, Non-Tool Specific)
10.6 Compliance Scope & Limitations
– Provider Does Not Act as Auditor/Assessor
– Provider Does Not Guarantee Certification
10.7 Technology Business Reviews (Cadence By Client Profile)
10.8 Security Communication Cadence
10.9 Cyber Liability Insurance Support

11. Client Operational Responsibilities

11.1 Authorized Contacts and Authorized Approvers
11.2 Accuracy of Information
11.3 Required Use of Ticketing & Change Management Processes
11.4 Hardware & Inventory Responsibilities
11.5 Facilities, Environmental, Power & Physical Requirements
11.6 Remote Work Responsibilities
11.7 Data Protection, Backup & SaaS Backup Expectations
11.8 Third-Party Application Support Requirements
11.9 Participation in Governance & Compliance Activities
11.10 Domain, DNS & Email Authentication Responsibilities
11.11 Browser, OS, and Device Standards
11.12 Naming Convention Requirements

12. Provider Operational Responsibilities

12.1 Monitoring & Alert Handling
12.2 Patch and Update Management
12.3 Configuration and Hardening
12.4 Documentation Maintenance
12.5 Enforcement of Minimum Requirements
12.6 Change Implementation
12.7 Emergency Actions
12.8 Limitations of Services

13. Telecom & Voice Services

13.1 Overview of Telecom & Voice Services
13.2 Number Porting & Provisioning
13.3 Device and Endpoint Configuration
13.4 Call Flow, IVR & Auto-Attendant Configuration
13.5 Telecom Consumption Billing Behavior
13.6 Regulatory Fees, E911, and Surcharges
13.7 Client Responsibilities
13.8 Limitations (Upstream Vendor Behavior, Carrier Delays, etc.)

14. Appendices

14.1 Included vs. Chargeable Services Matrix
14.2 Shared Responsibility Matrix
14.3 RACI Matrix for Managed vs. Co-Managed Services
14.4 High-Level Onboarding Checklist
14.5 High-Level KPI & Reporting Examples
14.6 Communication & Escalation Ladder
14.7 Revision History

**1. Introduction & How to Use This Guide

1.1 Purpose of This Services Guide

This Services Guide (“SG”) provides operational detail regarding the Services delivered by the Provider under applicable Statements of Work (“SOWs”). It is intended to help the Client understand how the Provider organizes, operates, and delivers the Included Services defined in the MSA.

This SG does not replace or modify the MSA. In any conflict or ambiguity, the MSA controls. All capitalized terms have the meanings given in the MSA.

1.2 Relationship to the Master Services Agreement

The Master Services Agreement governs the Parties’ legal rights, responsibilities, limitations, and terms of service.

This Services Guide is an operational companion to the Master Services Agreement. It describes how Services are delivered, how Service Categories are structured, and what Minimum Requirements, Unsupported Systems, and Risk Declinations mean in practice.

This Services Guide is not a contract. It does not create, expand or modify the legal rights, remedies, or limitations set out in the MSA or any SOW. However, where the MSA or an applicable SOW expressly refers to a Service Category, Minimum Requirement, Risk Declination, SLO concept, or other defined term that is further described in this Services Guide, the referenced portions of this Services Guide are incorporated into and form part of the Agreement.

Descriptions of internal teams, ticket flows, AI triage, escalation paths, and other operational practices are for context only and do not guarantee that those specific methods will be used in every instance.

1.3 Scope and Nature of This Document

This SG covers:

Operational delivery models
Support processes and escalation paths
Service components included within each service pillar
Roles within the Provider’s support structure
Client responsibilities and collaboration expectations
High-level workflows for incidents, changes, and governance processes
Baseline configurations and minimum environment standards required for effective service delivery

This SG does not provide legal definitions, contractual terms, or binding commitments. Those elements appear exclusively in the MSA and applicable SOWs.

1.4 Overview of Support Pillars

The Provider organizes its Services into three primary pillars:

AlignCORE

Operational IT Services covering support, device management, infrastructure management, cloud identity foundations, and general IT operations.

AlignSHIELD

Security Services that enhance the Client’s protection posture through detection, containment, whitelisting enforcement, vulnerability visibility, and coordinated security monitoring.

AlignASSURE

Governance, Risk & Compliance (GRC) Support providing policy development, framework alignment, evidence/documentation support, and risk assessment guidance. AlignASSURE complements AlignCORE and AlignSHIELD by strengthening the Client’s overall governance and compliance posture.

These pillars may be used independently or in combination depending on the SOW.

1.5 Intended Audience

This SG is designed for:

Client executives and operational leadership
Client IT stakeholders and Authorized Contacts
Client personnel with roles connected to technology, security, or compliance operations
Provider personnel responsible for service delivery

It is intended to provide a shared operational reference point across all Parties involved in service execution.

1.6 How to Use This Guide Together With the MSA and SOWs

To understand the entirety of the Services:

The MSA defines legal terms, obligations, limitations, and governance of the relationship.
The SOWs define which Services the Client has subscribed to, along with any Service-specific parameters.
This SG explains how those Services are delivered operationally, what is required to deliver them effectively, and how the Client interacts with the Provider.

If a term or practice appears in this SG that depends on contractual authority, the contractual authority resides exclusively in the MSA or applicable SOW.

Provider may update tools, operational methods, automation, and workflows as needed to maintain service quality, security, or compliance.

Updates to this SG are operational only and are governed by MSA §1.6.

1.7 What this SG Does NOT Do

It does not modify the MSA.
It does not create service entitlements.
It does not guarantee specific outcomes, SLOs, or remediation times.
It does not define pricing, fees, or commercial terms.
It does not replace security policies or legal/regulatory guidance.

2. Service Model & Support Structure

2.1 Provider Support Structure (CORE Team, TAC, NOC, SOC, TAM, GRC Team)

The Provider delivers Services through a coordinated, team-based support model. Several specialized teams work together to provide operational IT Services, Security Services, and Governance, Risk & Compliance (“GRC”) Support.

CORE (Client Oriented Responsive Engineering) Teams – Each Client is assigned to a dedicated CORE Team. CORE Teams are multidisciplinary engineering pods responsible for maintaining Client-specific context, architecture familiarity, business requirements, and operational continuity. While multiple CORE Teams exist within the Provider’s organization, each Client interacts with their assigned CORE Team as their primary point of ownership. All TAC, NOC, and SOC activities feed into the Client’s assigned CORE Team for oversight, review, and alignment with the Client’s goals and environment.

TAC (Technical Assistance Center) – A larger support pool providing 24×7 coverage for ticket intake, triage, troubleshooting, and escalation. TAC handles overflow during Business Hours and serves as the first-line responder after hours, on weekends, and on observed holidays.

NOC (Network Operations Center) – Monitors device-generated alerts and events across Managed Systems. The NOC does not communicate directly with the Client; it escalates operational or performance-related alerts to the CORE Team and/or TAC depending on timing and resource availability.

SOC (Security Operations Center) – Monitors Security Events, suspicious activity, and Indicators of Compromise. The SOC does not communicate directly with the Client; it escalates Security Events to the CORE Team for Client communication, decision-making, and authorization of follow-up actions.

TAM (Technical Account Manager) – Provides account oversight, pattern analysis on recurring issues, and guidance on improvements or required changes. The TAM may initiate Risk Declinations, project recommendations, or infrastructure changes based on observed risks or recurring incidents.

GRC (Governance Risk and Compliance) – Delivers AlignASSURE Support. The GRC Team provides policy development support, framework alignment, assistance with Security Risk Assessments, and guidance on evidence documentation. The GRC Team coordinates with the CORE Team as needed but is distinct in function. The GRC team cannot audit, operationalize, formalize or attest to any policy, control or regulation.

Licensing-Only Clients – Organizations that purchase licensing or cloud subscriptions from the Provider without receiving any operational services. Support is limited to vendor-directed Tier 1 assistance for the licensed product only.

Tiered Support Levels

Tier 1: Initial triage, basic troubleshooting, password resets, known-issue resolution, documentation lookup, and escalation routing.
Tier 2: Intermediate troubleshooting, configuration changes, log analysis, application-specific support, and vendor coordination.
Tier 3: Advanced engineering, root cause analysis, complex system remediation, architecture-level changes, and escalation to vendors for product defects.

2.2 Shared Resource Model (Team-Based Delivery; No Dedicated Personnel)

The Provider operates under a shared-resource model. Personnel are assigned to teams and service functions rather than to specific Clients. This ensures continuous coverage, reduces single points of failure, and provides access to a broader skill set across multiple disciplines.

Although the CORE Team serves as the Client’s primary operational point of contact, no individual or group is dedicated exclusively to any single Client unless otherwise defined in an applicable SOW.

2.3 Overview of AI-Assisted Triage & Ticket Routing (High-Level)

The Provider uses AI-assisted systems to classify, route, and enrich incoming tickets. These systems analyze factors such as incident type, priority indicators, device signals, and historical data to route tickets to the appropriate team (CORE Team or TAC).

AI triage improves response efficiency and ensures that tickets requiring specialized functions (such as security review or infrastructure analysis) are routed appropriately.

This triage system is used at all hours. After-hours tickets are typically routed directly to TAC for action, with the CORE Team reviewing relevant tickets on the next Business Day.

AI-assisted triage processes use operational and telemetry data only as permitted under the Provider’s data-use and confidentiality obligations defined in the MSA.

AI-assisted processes are augmentative only and may not identify all events, errors, or anomalies. Human review remains the authoritative resolution mechanism.

2.4 Availability of Services (24×7×365 Support Channels)

Support channels provided by the Provider—including telephone, email, and the Client-facing ticket portal—are available 24×7×365. Availability of these channels does not imply that all service pillars provide 24×7 client-facing support.

CORE (Managed Services) – Client-Facing Support Availability

Inbound, client-facing support is provided only under the AlignCORE service pillar. Clients subscribed to CORE may submit tickets or call for assistance at any time. After-hours responses follow the Support Structure outlined in this SG, with TAC providing triage and best-effort remediation and the CORE Team performing follow-up review during Business Hours.

SHIELD (Security Services) – Monitoring & Containment Availability

AlignSHIELD provides 24×7 security monitoring, alerting, and containment actions. These activities are performed by the SOC and are not client-facing.

Immediate containment actions (e.g., isolation, blocking, suspension) may occur at any time.
In-depth analysis, root-cause review, recommendations, and Client communication occur during Business Hours through the CORE Team.

ASSURE (Governance, Risk & Compliance Support) – Business Hours Only

AlignASSURE activities—including policy development, framework alignment, evidence support, and risk assessments—are performed by governance professionals and are available only during Business Hours. ASSURE is not a 24×7 support service and does not include after-hours or emergency response.

Service Availability vs. Remediation Availability

Service availability does not guarantee on-demand remediation or access to specific personnel at all hours. Response and resolution timelines are governed by:

The subscribed service pillar(s)
Operational practices
Business Hours
Applicable SLOs.

2.5 Business Hours (Client Primary U.S. Headquarters Time Zone)

The CORE Team operates during normal Business Hours, defined as 9:00 a.m. to 5:00 p.m. in the time zone of the Client’s primary United States headquarters location.

During Business Hours:

The CORE Team is the primary handler of incoming tickets.
TAC assists with overflow when ticket volume exceeds CORE Team capacity.

Outside Business Hours:

TAC handles all ticket intake and response.
Relevant tickets are reviewed by the CORE Team on the next Business Day.

2.6 Observed Holidays (U.S. Federal Holidays)

The Provider observes U.S. federal holidays for purposes of CORE Team availability. During these periods, the CORE Team is unavailable, and TAC continues to provide 24×7 support for ticket intake, triage, and best-effort resolution.

2.7 Communication Pathways

2.7.1 Client-Facing Teams (CORE Team, TAC)

The CORE Team and TAC are the only teams that communicate directly with the Client. Communication includes ticket updates, requests for information, troubleshooting steps, and coordination on changes.

TAC communicates with the Client for after-hours calls, high-volume periods, and tickets assigned to TAC by AI triage or overflow routing.

2.7.2 Non-Client-Facing Teams (NOC, SOC, Upstream Vendors)

The NOC, SOC, and Upstream Vendors do not communicate directly with the Client.

The NOC forwards operational alerts to the CORE Team or TAC.
The SOC forwards Security Events to the CORE Team for Client communication, decision-making, and risk-handling instructions.
Upstream Vendors communicate only with the Provider unless the engagement requires direct Client involvement.

This structure maintains a clear communication pathway and ensures consistent client experience and proper oversight by the Provider.

2.8 High-Level Incident and Event Flow

The Provider categorizes issues and events based on their source, which determines the initial handling team:

Client-Generated Incidents

Submitted through tickets, phone calls, or email.

During Business Hours → handled by the CORE Team, with TAC assisting during overflow.
After hours → handled by TAC, with next-day CORE review when appropriate.

Device-Generated Events (NOC)

Events from Managed Systems (servers, endpoints, network infrastructure, cloud services) are monitored by the NOC.

The NOC routes actionable alerts to CORE or TAC depending on timing and severity.

Security-Generated Events (SOC)

Security Events and Indicators of Compromise are monitored by the SOC.

The SOC contains or isolates threats when appropriate according to operational workflow.
The SOC notifies the CORE Team, which communicates Security Incidents to the Client and coordinates follow-up actions.

This tiered event-handling model ensures the appropriate team responds based on the nature, timing, and risk level of the issue.

3. Minimum Requirements, Baseline Governance & Unsupported Systems

The operational practices in this section reflect how the Provider implements the authority defined in the MSA, but do not create additional contractual obligations.

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

3.1 Purpose of Minimum Requirements (Service Delivery & SLO Eligibility)

Minimum Requirements ensure that the Services can be delivered effectively, securely, and reliably. These requirements support Service functionality, maintain the integrity of Managed Systems, and preserve eligibility for SLOs.

Systems or environments that do not meet Minimum Requirements may be classified as Unsupported Systems, which may affect the Provider’s ability to deliver Included Services and may suspend SLO applicability as described in the MSA.

The Client must maintain an active cyber insurance policy meeting the minimum coverage requirements defined in the MSA, including but not limited to coverage for ransomware, data breach, and business interruption.

Licensing-Only Clients are not subject to Minimum Requirements, as the Provider does not manage, monitor, or secure their systems.

3.2 Endpoint Requirements (Tools, Compliance, Health Expectations)

For the Provider to deliver Services effectively, all endpoints considered Managed Systems must meet the following operational baselines:

The endpoint must run a Supported System (as defined in the MSA).
Required security and management tooling must be deployed and functioning.
Device health signals (patch level, update status, device identity compliance) must not be suppressed, disabled, or overridden.
The device must remain powered on and connected to the internet regularly enough to receive updates, policies, and telemetry.
Local administrative rights should be restricted to approved roles or workflows to prevent security drift.

Endpoints that cannot consistently maintain management connectivity or tooling may be classified as Unsupported Systems.

Supported configurations include the use of modern, vendor-supported web browsers such as Microsoft Edge, Google Chrome, and Mozilla Firefox. The Provider does not support the use of Tor browsers or software primarily associated with anonymity networks, peer-to-peer file sharing, torrenting, or other applications that may introduce elevated security risk. Systems using such browsers or tools may be classified as Unsupported Systems.

**3.3 Directory and Identity Requirements

The Client must maintain an identity environment aligned with Provider security baselines. These requirements apply to all Managed Systems and are prerequisites for full supportability, SLO eligibility, and proper security operations.

These identity baselines support service delivery. Enforcement authority and compliance consequences are governed exclusively by the MSA’s Minimum Requirements and Risk Declination provisions.

3.3.1 Unique Identities

All users must authenticate using unique, individual accounts.
Shared user accounts, shared mailbox credentials, or unnamed local accounts are not permitted for accessing business systems.

3.3.2 Privileged Accounts

Privileged accounts (including domain-level, tenant-level, and administrative cloud roles) must follow strict identity governance:

Privileged accounts must be individually assigned and uniquely attributable.
Shared or unnamed privileged accounts for Client use are not permitted.
Privileged access must be limited to users with a documented business need.
Privileged accounts must be protected by MFA and meet Provider security baselines.
Privileged accounts may not be used as daily-driver accounts for general productivity, communications, development, browsing, or end-user workflows. All privileged accounts must be separate credentials from standard user identities. Users must perform daily activities using their standard account and elevate only when required through their designated privileged account to minimize attack surface, reduce credential exposure, and comply with identity security baselines.

3.3.3 Provider Privileged Access

The Provider uses privileged administrative access solely for the delivery of Managed Services.
Provider administrative accounts may:

utilize password rotation,
implement just-in-time authorization workflows,
use immutable audit logging systems,
include shared credentials for internal Provider teams as required for 24×7 service delivery.

Provider privileged accounts do not require Client access and are governed by Provider-controlled security and audit systems.

Clients must purchase and maintain appropriate licensing for Provider administrative identities. These identities are separate from Client user accounts and are required for management tooling, automation, monitoring, security operations, privileged access workflows, remote administration, and identity governance controls. Provider administrative accounts must remain licensed, active, and excluded from any automated deprovisioning or license reclamation processes. Failure to maintain licensing for Provider identities may result in suspension of services or inability to meet Service Level Objectives.

3.3.4 Identity Platforms

The Client must utilize a supported cloud identity platform such as Microsoft Entra ID or Google Cloud Identity. The Provider may require integration of identity tools necessary to enforce Minimum Requirements and support security operations.

All Managed Services Clients must maintain a Microsoft Entra ID tenant licensed at the level required for their subscribed service tier. AlignCORE Clients must maintain, at minimum, Microsoft Entra ID P1 or an equivalent Microsoft license that bundles Entra ID P1. AlignSHIELD Clients must maintain Microsoft Entra ID P2 or an equivalent bundled Microsoft license that includes Entra ID P2. These licensing requirements apply regardless of whether Clients primarily use Google Workspace or Google Cloud Identity for email or collaboration; Google-only identity environments are not supported for Managed Services.

The required Entra ID licensing enables identity synchronization, automation, privileged access separation, conditional access enforcement, SOC/SIEM integrations, and other security and operational workflows essential to the Provider’s service delivery. Clients must ensure that Entra licensing remains active and correctly assigned to all applicable users and Provider administrative identities.

3.3.5 Access Controls & Baselines

The Client must maintain:

MFA for all identities
Conditional Access or equivalent access controls
Unique privileged roles
Standardized identity lifecycle (onboard/modify/offboard)
No “shadow admin” creation by internal IT or 3PPs

Any deviation may result in risk classification, Required Remediation, or SLO Suspension.

3.3.6 Naming Convention Requirements

Clients must adopt and maintain the Provider’s standardized naming conventions for users, devices, groups, identities, and other managed objects. Standardized naming is required to support identity governance, automation workflows, lifecycle management, endpoint onboarding, licensing accuracy, security event correlation, SIEM/SOC integration, and application/network whitelisting processes.

Deviations from the Provider’s naming standards may result in synchronization failures, identity mismatches, automation errors, or delays in service delivery. Naming conventions may evolve over time as platforms and security requirements change, and Clients are required to apply updated standards when onboarding users, provisioning devices, or deploying new resources.

3.4 Network and Infrastructure Requirements

3.4.1 UPS Requirements (Network Infrastructure and Servers)

Network infrastructure devices (firewalls, switches, wireless controllers) and servers used as Managed Systems must be protected by Uninterruptible Power Supply (UPS) units to prevent unexpected outages, configuration corruption, and data loss.

3.4.2 Cooling & Environmental Conditions

Network and server equipment must operate in environments with adequate cooling, dust control, and reasonable environmental stability. Equipment positioned in unventilated, dirty, or unstable environments may generate persistent alerts or premature failures and may limit the Provider’s ability to meet SLO targets.

3.4.3 Rack, Cabling & Labeling Standards (Provider Managed)

The Provider maintains rack organization, labeling, and structured cabling for network infrastructure under Managed Services. Third-party cabling or unmanaged racks may require remediation work before onboarding.

3.4.4 Commercial Hardware Requirements

All endpoints and servers used in the Managed Environment must be commercial-grade devices with appropriate business warranties and business-class operating systems (e.g., Windows Pro/Enterprise). Devices purchased through consumer retail channels (e.g., Best Buy, Costco, mass-market online retailers) may not meet security, warranty, or manageability standards required for Managed Services. Such devices may require remediation, reimaging, or full replacement prior to acceptance into management.

Hardware standards and security requirements naturally evolve over time. The specifications required for supported devices may change as operating systems, security tools, and vendor platforms advance. Clients must ensure that any new hardware purchased for use in the Managed Environment meets the Provider’s current Minimum Requirements at the time of purchase. Older devices that previously met standards may become unsupported as requirements change.

3.5 Internet & Connectivity Expectations (Dual WAN / 5G Backup Recommended)

Reliable connectivity is essential for Managed Systems. The Provider recommends:

Dual WAN circuits where practical,
or a 5G/LTE failover solution.

The Provider may review ISP invoices to identify cost savings or alternative circuit options through brokerage partners, but the Client maintains responsibility for establishing, maintaining, and paying for all circuits and carrier services.

The Provider does not assume responsibility for ISP outages, circuit quality, or upstream carrier issues.

Client is responsible for maintaining active service agreements with ISPs and carriers.

3.6 Remote Work Baseline Assumptions and Limitations

Remote environments are considered untrusted by default. The Provider assumes devices may connect through open or untrusted networks (e.g., public WiFi).

Remote employees must:

Use Managed Systems with required tooling installed.
Use MFA for all access to cloud resources and business systems.
Use Provider-approved VPN or Zero Trust access technologies where necessary.
Maintain device compliance and health standards.

The Provider does not manage or support home network configurations, personal router setups, home WiFi performance, or environmental conditions in residential settings. Failures in these areas may affect service delivery and SLO applicability.

Provider does not monitor, secure, or troubleshoot home WiFi networks, personal routers, or consumer-grade network equipment. Remote environments are inherently untrusted, and Client users must rely on Provider-managed devices meeting Minimum Requirements for full supportability.

3.7 Baseline Cybersecurity Policies (Required for Clients Receiving Managed Services)

Clients receiving AlignCORE Services must adopt baseline cybersecurity policies. The provider will provide unreviewed and unedited templates that may be modified by the Client as long as the intent and protective purpose remain intact. The baseline policy set includes:

Written Information Security Policy
Termination Policy
Security Incident Response Policy
Sanction Policy
Network Security Policy
Access Controls Policy
Computer Use Policy
Disposal Procedure
BYOD Policy
Facility Security Plan

Clients receiving AlignASSURE Services may adopt framework-specific policies instead of these baseline policies.

Failure to adopt minimum governance standards may result in Risk Declination and/or Unsupported System classifications.

3.8 Zero Trust Baseline Requirements

The Provider follows a Zero Trust model for Managed Systems. The following subsections describe the key security controls and enforcement mechanisms used to implement this model.

3.8.1 Multi-Factor Authentication

MFA must be enabled for all Cloud Services, administrative roles, and remote access technologies.

3.8.2 Conditional Access Requirements

Conditional Access policies may be recommended or required to enforce identity and device compliance, based on Service tier and environment maturity.

3.8.3 Device Compliance

Devices must meet compliance standards defined by the Provider’s management tools (e.g., encryption, password/PIN requirements, secure boot, patch level).

3.8.4 Application Whitelisting

Clients using SHIELD Services are subject to an application and network whitelisting security model. By default, unapproved applications, scripts, processes, and network actions are blocked until reviewed. The full operational workflow for application and network whitelisting, including SOC triage, CORE review, risk declination, and client communication expectations, is detailed in Section 8.10 (Application & Network Whitelisting Workflow).

3.8.5 Network Whitelisting (Default Deny for Clients Receiving SHIELD Services)

Network whitelisting is applied to Clients receiving AlignSHIELD Services, using a default-deny
SHIELD Services include a default-deny network security model in which outbound network connections, destinations, or protocols that are unrecognized or unapproved may be blocked until reviewed. Network whitelisting requirements and enforcement expectations are part of the SHIELD Minimum Requirements. The full operational workflow for evaluating and approving network connections is described in Section 8.10 (Application & Network Whitelisting Workflow).

3.9 Unsupported Systems

3.9.1 Definition & Examples

Unsupported Systems are those that do not meet Minimum Requirements, cannot maintain required tooling, apply to deprecated or insecure platforms, or operate outside the Provider’s Supported Systems list as defined in the MSA.

Examples include:

End-of-life operating systems
Unmanaged personal devices
Devices without required security tools
Legacy or proprietary hardware lacking vendor support
Systems the Client prohibits the Provider from managing
Systems operated by Third-Party Providers outside coordinated processes

3.9.2 Effect on Included Services and SLOs

Unsupported Systems may:

Fall outside Included Services
Require Chargeable Services for remediation
Reduce or suspend SLO applicability
Limit the Provider’s ability to diagnose or resolve issues
Trigger Risk Declinations

The Provider may recommend remediation, replacement, or isolation of Unsupported Systems as needed.

**3.9.6 Domain Ownership, DNS Management & Email Authentication Requirements

The Provider does not own, register, or take legal ownership of any Client domain names. All domains must be registered to an authorized individual end user within the Client organization. Clients are encouraged to transfer domain registrations to the Provider’s supported registry platform (operated by HTML Global Self Service provided by Wild West Domains, LLC, a GoDaddy subsidiary), which enables the Provider to administer DNS and security configurations while maintaining Client ownership.

Clients must provide and maintain an off-domain email address for all domain registrations and ICANN-related notifications, and must designate a valid individual in each required geographic region to serve as the registrant contact. ICANN regulations require accurate registrant data, and Clients are responsible for updating and maintaining this information.

All Managed Services Clients must host DNS for Client-owned domains on the Provider-managed DNS platform. Third-party marketing firms, web developers, and other vendors are not permitted to manage DNS or make DNS changes. All DNS modifications must be submitted as a ticket request to the Provider.

The Provider enforces DMARC, SPF, DKIM, and related email authentication policies. Any third-party system or service that sends email on behalf of a Client domain must be reviewed, approved, and validated by the Provider before sending begins. Unapproved senders or misconfigured systems may be blocked or quarantined as part of the Provider’s email security controls.

These DNS and domain requirements describe operational best practices. Contractual rights, obligations, and limitations are governed exclusively by the MSA.

Third-party senders must be approved by an Authorized Approver before Provider will configure DNS/authentication records.

3.10 Risk Declination (Operational Overview)

The operational practices in this section reflect how the Provider implements the authority defined in the MSA, but do not create additional contractual obligations.

When the Client elects not to implement a recommended control, configuration, or remediation, the Provider may issue a Risk Declination. This is documented by the TAM or CORE Team and stored in the Client’s records.

Operationally, a Risk Declination:

Indicates the Client has chosen not to implement a recommended security measure.
May reclassify affected systems as Unsupported Systems.
May suspend SLO applicability for related systems or Services.
Guides future strategic recommendations and reporting.

Risk Declinations do not alter the Parties’ contractual obligations but help maintain security clarity and operational alignment.

Operational workflow shown here does not alter the legal effects of a Risk Declination as defined in MSA §6.4.

4. Service Pillars (AlignCORE, AlignSHIELD, AlignASSURE)

The Provider organizes its Services into three primary pillars. Each pillar represents a distinct operational function, and Clients may subscribe to one or more pillars depending on their needs and applicable SOWs. These pillars are complementary but intentionally separated to maintain clarity around operational scope.

The operational practices in this section reflect how the Provider implements the authority defined in the MSA, but do not create additional contractual obligations.

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

4.1 AlignCORE – Managed Services

4.1.1 Overview of Included Services

AlignCORE provides the foundation of Managed Services. It delivers day-to-day IT operations, endpoint management, infrastructure management, cloud identity administration, and general end-user support. AlignCORE is focused on operational continuity, device health, network stability, and user productivity across Managed Systems.

This pillar forms the baseline operational layer upon which AlignSHIELD and AlignASSURE expand.

4.1.2 Helpdesk & User Support

The Provider delivers end-user support through the combined efforts of the CORE Team and TAC. Support includes:

Assistance with business applications (within documented Vendor support boundaries)
Troubleshooting user issues on Managed Systems
Password resets, MFA support, and account access assistance
Peripheral troubleshooting (keyboards, mice, webcams, monitors)
Standard workstation configuration and setup
Ticket triage and root-cause investigation for recurring issues

Support is delivered through the Provider’s established communication channels and governed by operational practices and applicable SLOs.

4.1.3 Endpoint & Server Management

AlignCORE includes operational management of supported endpoints and servers, including:

Health and compliance monitoring
Patch and update management
Baseline configuration and policy deployment
System performance monitoring
Periodic reviews of system signals and alerts
Join/leave workflows for new and decommissioned devices
Coordination of warranty repairs or Vendor support cases where applicable

The Provider manages these systems remotely unless onsite work is scoped separately in a SOW.

4.1.4 Network & Infrastructure Management

The Provider manages supported network infrastructure components, including firewalls, switches, wireless access points, and related systems.

Operational activities include:

Monitoring of device-generated alerts via the NOC
Configuration management and change execution (subject to ticket approval)
Firmware and software update coordination
Connectivity troubleshooting
Wireless and LAN configuration tasks
Coordination with Upstream Vendors (carriers, ISPs) as needed
Review of ISP circuits and carrier services upon Client request

Physical remediation or cabling work may require separate scoping.

4.1.5 Cloud Identity & Collaboration (Baseline Configuration)

AlignCORE provides configuration and management of cloud identity and collaboration services, including:

Administration of Entra ID, Google Cloud Identity, and associated object lifecycles
MFA configuration and support
Conditional Access recommendations and enforcement (based on MSA authority and SOW scope)
Group-based access controls and basic role assignments
Licensing assignment and change coordination (see Access Licensing in MSA)
Baseline configuration of collaboration platforms (e.g., email, file storage, messaging)

AlignCORE establishes and maintains identity and access foundations required for AlignSHIELD and AlignASSURE to function effectively.

Note: Licensing-Only Clients do not receive any AlignCORE Managed Services unless separately contracted.

4.2 AlignSHIELD – Security Services

These services improve visibility and context but do not create obligations to detect, prevent, certify, or guarantee compliance or security outcomes.

4.2.1 Overview of Security Protections

AlignSHIELD enhances the Client’s security posture by providing layered defensive controls, continuous monitoring, application and network whitelisting enforcement, vulnerability visibility, and collaboration with the SOC. AlignSHIELD does not replace good governance practices; it builds on AlignCORE’s operational baselines.

4.2.2 Application and Network Whitelisting Enforcement

AlignSHIELD applies a default-deny security model:

Application whitelisting controls which executables, scripts, and applications may run.
Network whitelisting controls which outbound network destinations are allowed.

The Provider reviews whitelisting events and surfaces required approvals through the ticketing system.

Changes or exceptions must be submitted as tickets or change requests.

Whitelisting reduces attack surface but does not detect or prevent all malicious behavior. No whitelisting model is guaranteed to be error-free or threat-proof.

4.2.3 Security Monitoring (SOC Integration)

The SOC continuously monitors Security Events, Indicators of Compromise, and suspicious activity across Managed Systems. Operational activities include:

Detection and automated or manual containment actions
Analysis and classification of potential threats
Notification to the CORE Team
Documentation of security findings

The SOC does not communicate directly with the Client. All Client communication occurs through the CORE Team to ensure consistent handling and streamlined decision coordination.

4.2.4 Vulnerability Identification & Remediation (Risk-Based; CVSS)

AlignSHIELD includes ongoing identification of potential vulnerabilities across Managed Systems. While the Provider does not disclose toolsets, telemetry sources, or scanning cadences in this SG, AlignSHIELD provides:

Continuous or periodic vulnerability visibility
Contextual analysis based on CVSS scoring
Prioritization recommendations
Remediation options aligned to business impact and risk tolerance
Risk Declinations for deferred or declined remediation

Remediation activities may require change-management approval or additional project scoping depending on system impact.

4.2.5 Security Incident Handling (Scope & Limitations)

Security Incidents identified by the SOC are escalated to the CORE Team for Client communication. Operational handling includes:

Reviewing SOC findings
Coordinating containment, isolation, or rollback actions
Gathering relevant device or identity information
Presenting remediation recommendations

The Provider does not offer digital forensics, law enforcement coordination, or full incident response retainers. If such services are required, the Provider may coordinate with a Third-Party Provider per the MSA. Security Incident handling does not include testimony, depositions, court appearances, or participation in insurance investigations unless separately scoped.

Note: Licensing-Only Clients do not receive AlignSHIELD Security Services, monitoring, SOC review, or security tooling unless separately contracted.

4.3 AlignASSURE – Governance, Risk & Compliance Services

**4.3.1 Framework Alignment

AlignASSURE provides support towards alignment with security standards and compliance frameworks. The Provider assists Clients by interpreting framework requirements and mapping them to operational or technical controls.

This service does not constitute certification, auditing, or attest services.

**4.3.2 Standards & Compliance Governance Lifecycle

AlignASSURE supports an ongoing governance lifecycle for security policies and procedures. Policy governance under AlignASSURE is a continuous program, not a project-based deliverable, and evolves based on changes in risk, operations, and applicable frameworks identified in the SOW.

AlignASSURE policy governance encompasses two areas:

Security Standards – control-based security frameworks that guide maturity and technical alignment.
Compliance Frameworks – regulatory or certification-driven programs for which the Provider supplies technical alignment and evidence support as scoped in the SOW.

The Provider supports policy governance activities such as:

Preparing initial draft or framework-aligned baselines
Collaborating with the Client to refine and contextualize policy content
Reviewing for consistency across the Client’s governance program
Assisting with adoption and implementation guidance
Maintaining ongoing updates driven by risk assessments, audits, maturity objectives, and changes in security or compliance requirements
Supporting attestation or review cycles where applicable
Ensuring continued alignment between policy, controls, and operational practices

The Provider does not interpret legal or regulatory obligations, determine compliance status, or act as an auditor or certifying authority. The Client is responsible for internal enforcement and all legal or regulatory compliance determinations.

4.3.3 Security Risk Assessments (SRA)

The Provider performs Security Risk Assessments according to the Client’s subscribed service tier:

AlignCORE – SRAs performed on request or as separately scoped engagements
AlignSHIELD – Incorporates ongoing automated visibility and targeted reviews
AlignASSURE – Includes human-led SRAs aligned to applicable frameworks

SRA outputs may include identified risks, recommended mitigations, and updates to the Client’s risk posture.

4.3.4 Evidence & Documentation Support (Generalized)

AlignASSURE provides guidance and support in producing security and compliance evidence. Depending on engagement scope, evidence may be:

Provided by the Provider
Gathered by the Client
Generated through collaboration between the Client, CORE Team, and GRC Team

Evidence examples may include screenshots, configurations, policy documents, or summaries—but toolsets and operational cadence are not disclosed in this SG.

4.3.5 Technology Business Reviews and Strategic Planning

The Provider conducts Technology Business Reviews (“TBRs”) to align technology strategy with business objectives. TBRs may cover:

Review of incidents and recurring issues
Evaluation of security posture and identified risks
Assessment of governance or compliance gaps
Prioritized recommendations
Roadmaps for improvement

Cadence varies based on Client size, service tier, and business needs.

Note: Licensing-Only Clients do not receive AlignASSURE governance, risk, compliance, assessment, or policy services unless separately contracted.

5. Fees, Billing, Licensing & Payment Terms

**5.1 Fees and Rate Structures (Included vs. Chargeable Services)

This SG provides operational clarity regarding Services that are typically Included Services versus those that may require Chargeable Services.

The specific Fees, rates, quantities, and commercial commitments are defined in the applicable SOW. This section only describes operational behavior.

Included Services generally consist of:

Tasks covered by the Service Pillar(s) subscribed to by the Client
Support activities within Managed Systems meeting Minimum Requirements
Work that falls within baseline operational functions of AlignCORE, AlignSHIELD, or AlignASSURE

Chargeable Services may include:

Work performed on Unsupported Systems
After-hours work that the SOW defines as billable
Remediation of Client-made configuration changes without tickets
Major changes requiring TAM involvement where not Included Services
Projects, migrations, or complex changes requiring planning or engineering
Work related to Third-Party Providers not coordinated through standard channels

The Provider uses the ticketing system and SOW to help determine whether a request falls within Included or Chargeable Services.

Annual adjustments to recurring Fees are governed solely by Section 5.1 of the MSA.

Provider may suspend Services, access to Managed Systems, or access to the Provider Environment for non-payment or other material breach as described in MSA Sections 4.5 and 5.1.

5.2 Invoicing and Billing Cycle Anchor Date

Invoices are generated according to the billing cycle and schedule defined in the SOW. The billing cycle anchor date is typically the initial activation date of the first Service provided under an applicable SOW, after which recurring billing aligns to that monthly cycle.

Operationally:

Recurring Fees are invoiced in advance.
Consumption or usage-based Fees may be invoiced in arrears.
Project Fees or non-recurring Services may follow milestone or completion-based invoicing as outlined in the SOW.

If Services change mid-cycle (such as user count adjustments or license changes), prorations follow the billing logic defined in the SOW and MSA.

5.3 Payment Terms and Methods

Payment terms are as defined in the MSA and SOW. This SG provides operational clarification only.

The Provider accepts commonly used payment methods such as ACH, electronic payment platforms, or other methods defined in the SOW. Clients are encouraged to use automated or electronic payment methods to avoid disruptions to Services.

5.4 Late Fees, Interest, and Collection Costs

This SG does not restate any legal obligations. Any late fees, interest assessments, service suspensions, or recovery actions follow the provisions set forth in the MSA.

Operationally, the Provider may notify the Client through ticketing or email when payments are past due to maintain awareness and prevent service disruption.

5.5 Taxes and Regulatory Fees (Including Telecom-Related Fees)

Invoices may include pass-through taxes, fees, or regulatory surcharges as required by law or imposed by Upstream Vendors.

Examples include:

Telecom or VoIP regulatory fees
E911 fees
Cloud platform taxes
Usage-based surcharges from carriers or cloud providers

These charges originate from Upstream Vendors and may vary without notice. The Provider does not control these fees but passes them through transparently based on Vendor billing.

5.6 Invoice Disputes and Resolution Timelines

If the Client identifies an issue with an invoice, the Client should notify the Provider promptly through the designated billing or ticketing channel.

Operational handling includes:

Opening a billing ticket for investigation
Reviewing SOW quantities, usage, or metering
Coordinating with Upstream Vendors when necessary
Communicating findings and next steps

Any deadlines or procedures for formal disputes are governed by the MSA.

5.6.1 Billing Questions vs. Operational Charge Explanations

The Billing Department can assist with payment status, billing cycles, invoice formatting, term dates shown on invoices, taxes, credits, and the application of charges to specific service periods. However, Billing cannot interpret operational drivers behind charges, licensing requirements, user counts, billable activities, compliance-related labor, or the reasons certain items appear on an invoice.

Any questions involving the “why” behind a charge—such as licensing needs, user/device count changes, project scope adjustments, compliance requirements, or service usage—must be directed to the Client’s Technical Account Manager (TAM) or Primary CORE Team. Billing works from invoice data; operational explanations must come from the teams responsible for managing the Client’s environment.

5.7 Access Licensing Administration

Access Licensing (as defined in the MSA) applies to Microsoft 365, Google Workspace, cloud identity platforms, security products, SaaS tools, or other systems requiring per-user or per-device licensing. Operational expectations vary based on the licensing model.

5.7.1 Provider-Managed Access Licensing

Where the Provider manages Access Licensing:

The Client submits requests for adds/changes/removals through the ticketing system.
The Provider procures or allocates licenses based on Client approval from an Authorized Approver.
Lead times may vary based on Vendor processing or availability.
True-up or reconciliation processes follow Vendor and SOW rules.

5.7.2 Client-Managed Access Licensing

Where the Client manages its own licensing:

The Client remains responsible for ordering, maintaining, and renewing Access Licensing.
The Provider will perform administrative tasks only once valid licenses are active.
Lapses in licensing may cause downtime, degraded functionality, or Unsupported Systems.

5.7.3 Non-Cancellable License Commitments and True-Up Rules

Some licenses acquired through Upstream Vendors may have minimum terms, quantities, or true-up obligations.

Operationally, this may mean:

Quantities cannot be reduced until the Vendor’s term ends
Additions may immediately increase minimum commitments
True-ups may occur during annual or semi-annual Vendor review cycles

These behaviors are controlled by Vendor terms, not by the Provider.

5.8 Consumption Services Billing

Consumption Services (such as cloud compute, storage, serverless functions, egress, telecom minutes, or on-demand resource expansion) are billed based on actual usage as measured by Upstream Vendors.

5.8.1 Metered Usage and Upstream Vendor Meters

Usage meters and consumption metrics originate from the applicable cloud or telecom Vendor.
The Provider does not modify Vendor meters.
Consumption fees may vary month to month.

5.8.2 Cloud Continuity and Risk Mitigation Fees

Where applicable, resource governance, backup services, or ransomware mitigation measures may carry consumption-based Fees as defined in the SOW.

5.8.3 Forced Termination of Consumption Services and No-Restoration Obligation

If the Client terminates a cloud or consumption-based Service, Vendor-imposed consequences may apply (e.g., data deletion, loss of snapshots, loss of backups).

Operationally, once a Service is terminated or deprovisioned at the Client’s direction:

Data may not be recoverable
Restoration may not be possible
The Provider may require a separate project to rebuild or re-enable services

These behaviors stem from Vendor design and are not controlled by the Provider.

5.9 Telecom & VoIP Services Billing (Consumption + Regulatory Fees)

Telecom and cloud voice services may involve consumption-based billing (minutes, SMS, call routing, toll-free usage) and various regulatory fees.

Operational considerations:

Billing is based on Vendor call detail records
Rates may vary based on geography, usage type, and Vendor updates
E911 fees and regulatory compliance charges are typically non-negotiable
Number porting, new number assignments, and carrier moves may involve non-recurring charges

The Provider will relay Vendor billing or usage summaries upon request.

5.10 Suspension and Reinstatement for Non-Payment

Operational handling of service suspension due to non-payment follows the MSA.

If Services are suspended:

Access to support may be limited
Remediation or reinstatement may require Chargeable Services
Certain systems may require re-onboarding if tooling or configurations drift during suspension

The Provider will communicate reinstatement steps through the ticketing system after payment issues are resolved.

6. Ticketing, Escalation & Change Management

6.1 Ticket Submission Channels (Portal, Email, Telephone)

The Provider delivers Services primarily through a centralized ticketing system. The Client may submit tickets using:

The Client Portal
Email to the designated support address
Telephone (24×7×365)
Microsoft Teams (via the Provider’s official Teams application)
Slack (via the Provider’s official Slack application)

All requests, incidents, and change-related activities must be logged through the ticketing system. This ensures traceability, auditability, and proper routing to the appropriate team (CORE Team or TAC) and supports accurate reporting, SLO measurement, and structured change management.

Tickets must include relevant details such as the affected user, device, system, or service, along with a clear description of the issue or request.

Licensing-Only Clients may submit tickets only for licensing-related issues or Tier 1 vendor-directed support. Operational tickets, infrastructure issues, user support requests, or security events fall outside the scope of Licensing-Only Services.

6.2 Overview of AI-Assisted Triage

The Provider uses AI-assisted triage tools to classify and route incoming tickets. This process examines incoming requests for:

Incident type and severity
Impacted systems
Signal or telemetry patterns
Historical context
Keywords or indicators that suggest escalation needs

AI triage assists in determining the appropriate team (CORE Team or TAC) and may pre-classify tickets to improve response efficiency and accuracy.

AI triage operates 24×7 and is used for both Client-submitted and system-generated tickets.

6.3 Business-Hours Ticket Flow (CORE Primary, TAC Overflow)

During Business Hours (9:00 a.m.–5:00 p.m. in the Client’s primary U.S. headquarters time zone):

CORE Team Responsibilities:

Acts as the primary handler of incoming tickets
Provides end-user support, system troubleshooting, and operational remediation
Validates and reviews work performed by TAC on Client tickets
Coordinates with the TAM for recurring-pattern issues or strategic concerns

TAC Responsibilities:

Handles overflow when ticket volume exceeds CORE Team capacity
Works tickets escalated through AI triage or by CORE Team assignment
Performs troubleshooting up to and including Tier 3 activities

All ticket activity—regardless of which team is handling the work—is visible within the same unified ticket record.

6.4 After-Hours & Holiday Ticket Flow (TAC Primary; CORE Review Next Business Day)

Outside Business Hours, and during U.S. federal holidays observed by the CORE Team:

TAC handles all ticket intake and response
TAC performs best-effort remediation up to Tier 3
AI triage routes urgent or high-severity issues directly to TAC for immediate handling

On the next Business Day, the CORE Team reviews after-hours tickets that:

Contain significant changes
Impact critical systems
Require follow-up or validation
Require Client communication or further action

This ensures continuity, quality, and oversight while maintaining 24×7 availability.

6.5 Severity Levels & Prioritization

Tickets are assigned severity levels based on operational impact. While specific SLOs are defined later in this SG, severity classification is consistent across service tiers.

Typical severity considerations include:

Critical: Full outage affecting many users or core business systems (Phone Call Required)
High: Major degradation or issues affecting multiple users or critical workflows
Medium: Issues affecting individual users or non-critical systems
Low: Routine requests, minor issues, informational inquiries

AI triage may automatically assign an initial severity, which the CORE Team or TAC may adjust based on updated information.

For site-down situations, Clients are required to call directly and not rely on electronic ticket entry methods.

**6.5.1 Priority Reclassification Authority

The Provider may adjust the priority of a ticket at any time based on actual business impact, urgency, risk, and available workarounds. Examples include:

Downgrading severity when the impact is limited, a workaround exists, or the issue does not materially affect operations.
Upgrading severity when security alerts, monitoring signals, or infrastructure conditions indicate elevated risk.
Reclassifying mis-prioritized requests to ensure fair and accurate queue management.

Priority reclassification does not affect SLO applicability unless suspension factors apply (see §7.3).

6.6 Escalation Paths

Escalation ensures that tickets receive the appropriate expertise based on the nature of the issue.

CORE ↔ TAC Escalation

CORE Team may escalate high-volume or specialized requests to TAC
TAC escalates issues back to CORE Team when business knowledge, decision-making, or oversight is required

NOC → CORE/TAC

Device-generated alerts are forwarded to CORE or TAC depending on timing and availability
NOC does not interact directly with the Client

SOC → CORE

SOC escalates Security Events to the CORE Team only
SOC does not escalate directly to TAC
CORE Team handles Client communication for all Security Incidents

TAM Involvement

The TAM becomes involved when:

There are recurring issues or systemic patterns
Potential Risk Declinations are identified
Strategic or long-term changes may be required
A change request may impact multiple systems or users

Escalation paths ensure clarity, accountability, and proper governance of each request.

No Escalation by Copying Individuals
Escalation of incidents or service requests occurs only through the escalation paths and severity classification mechanisms defined in this Services Guide. Copying, messaging, or otherwise contacting individual Provider personnel, including account managers, technical account managers (TAMs), engineers, or leadership, does not constitute escalation and does not change ticket priority, severity level, response time, or handling.

Individual Provider personnel may be unavailable due to workload, meetings, time off, or other obligations and are not responsible for monitoring or triaging support requests outside the ticketing system. Requests to escalate an issue must be made within the applicable ticket using the defined escalation process.

6.7 Change Management

All changes—whether initiated by the Client or by the Provider—must follow a structured change process using the ticketing system. This ensures proper documentation, traceability, and alignment with security and operational standards.

6.7.1 Scheduled Changes (General Principle)

The Provider performs changes as scheduled tasks. Systemic configuration changes, infrastructure modifications, identity or access control changes, and whitelisting updates are not performed ad hoc or reactively.

Changes follow internal review and scheduling to minimize business impact.

6.7.2 Written Approvals from Authorized Approvers

Changes requiring Client authorization—such as configuration modifications, firewall or networking changes, application or network whitelisting exceptions, or identity role adjustments—must be approved by an Authorized Approver through the ticketing system.

Approvals must be documented in writing.
Phone authorizations may be accepted only when accompanied by written confirmation.

6.7.3 Changes Requiring TAM Involvement

The TAM is involved in changes that:

Impact multiple users, departments, or workflows
Have cost implications
Require business-case evaluation
Introduce training or change management needs
Might necessitate a Risk Declination (e.g., bypassing a recommended control)
Affect long-term roadmap or architecture decisions

The TAM provides context and coordination for higher-impact changes.

6.7.4 Low-Impact Changes via Ticket Response

Changes with minimal operational impact—such as granting access to an existing application, adjusting a group membership, or applying minor workstation settings—may be completed directly by CORE Team or TAC within the ticket.

These changes do not require formal change windows or TAM involvement unless tied to a systemic issue or recurring pattern.

6.7.5 Emergency Changes (Client Decision Authority; Provider Advisory Role)

In urgent situations—such as Security Incidents, outages, or imminent risks—the Provider may recommend emergency changes.

Operational handling:

The Provider advises on risks, benefits, and actions
The Client makes the final decision (consistent with the MSA)
Written approval is still required, but may follow after verbal approval if timing demands
Post-change review may be performed on the next Business Day

Emergency changes are limited to risk mitigation or service restoration actions.

6.8 Ticket Lifecycle & Closure Policy

To maintain clarity, efficiency, and accuracy in service delivery, the Provider follows the ticket lifecycle practices below. These practices ensure requests can be properly tracked, triaged, and resolved while maintaining alignment with Minimum Requirements and SLO eligibility.

6.8.1 One Issue per Ticket

Each ticket must address one issue, request, or change.
Submitting multiple unrelated issues within a single ticket may delay resolution, complicate prioritization, or affect SLO applicability.

If multiple issues are reported together, the Provider will:

Resolve the primary issue and request separate tickets for others

This ensures accurate tracking, proper prioritization, and clear historical records.

6.8.2 Required Client Information

If the Provider requests additional information (e.g., screenshots, error messages, user details, access approvals, vendor contacts), the ticket will remain in a Pending Client status until the requested information is received.

Tickets lacking required information may not be actionable and may not be subject to SLOs.

6.8.3 Follow-Up Attempts and Ticket Staleness

When the Provider requests information or clarification from the Client, the Provider may make up to three (3) follow-up attempts through the ticketing system or other approved communication channels.

If the Client does not respond after these attempts, the ticket will be:

Closed due to inactivity at the Provider’s discretion.

Clients may reopen the ticket at any time by replying in the same thread or submitting a new ticket referencing the original.

6.8.4 Automatic Closure of Inactive Tickets

Tickets may be closed automatically if:

The Client confirms the issue is resolved
No response is received after multiple follow-ups
The issue is determined to be non-actionable without additional Client input
The request is replaced by a new request (e.g., updated requirements)

Closure of inactive tickets ensures the accuracy of support metrics and prevents outdated items from remaining open indefinitely.

6.8.5 Ticket Reopening Policy

Closed tickets may be reopened if:

The same issue recurs
Additional information becomes available
The Client requires follow-up related to the same event or change

If the reopened ticket represents a new or materially different issue, a new ticket may be required for proper tracking.

6.8.6 Tickets for Extended or Project-Based Work

If a ticket requires:

Multi-day effort
Complex configuration
Cross-system dependency
Significant downtime coordination
Large-scale user or system impact
Budget approval
Engineering or architecture changes

…it may be reclassified as a Project, Change Request, or SOW-driven activity in coordination with the TAM.

Tickets are not intended to substitute for projects and cannot be used for work that falls outside Included Services.

**6.8.7 Customer Satisfaction Feedback (CSAT)

Each ticket closure email contains a Customer Satisfaction (CSAT) survey link. Clients are encouraged to complete the CSAT survey whenever feasible, as this feedback is an important component of the Provider’s service quality program.

Negative CSAT responses are surfaced immediately to the Client’s CORE Team and escalated to the Technical Account Manager (TAM), and when appropriate, to senior leadership. Clients should expect follow-up communication when negative feedback is submitted so the Provider may address the concern, clarify context, or implement corrective actions. CSAT follow-up does not modify or reopen the underlying ticket unless the Client submits additional communication through official support channels.

Positive CSAT responses are reviewed on a biweekly cycle. Comments submitted through positive CSAT feedback are not monitored in real time and are not considered part of the ticket communication process. Any information relevant to resolving an incident, requesting additional assistance, or clarifying work performed must be communicated directly within the ticket itself and not through the CSAT form.

CSAT feedback—positive or negative—is separate from Service Level Objectives (SLOs). Ticket-related communication must occur through the official channels defined in Section 6.1.

6.8.8 SLO Applicability to Ticket Lifecycle

SLOs apply only when:

The ticket contains complete and accurate information
Minimum Requirements are met
The Client responds to Provider follow-ups in a timely manner
The issue relates to properly onboarded Managed Systems
No suspension factors are active (as defined in SG §7.3 and the MSA)

Tickets pending Client information are not subject to SLO targets.

7. Service Level Objectives & Reporting

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

7.1 SLO Response Targets

Service Level Objectives (“SLOs”) define expected response timelines based on ticket severity. SLOs are targets, not guarantees, and reflect operational norms for Managed Systems that meet Minimum Requirements.

Typical response expectations may include:

Critical: Immediate response during Business Hours; prioritized after-hours by TAC
High: Rapid response within Business Hours; prompt triage after-hours
Medium: Standard response during Business Hours
Low: Best-effort response within normal operational queues

Specific SLO targets, including response times, are defined later in this SG and are subject to the conditions described in Section 7.3.

Response times referenced in any client-facing materials, such as the Client Manual, are descriptive targets only and do not create guarantees or modify the MSA or this Services Guide.

Licensing-Only Clients are not eligible for any Service Level Objectives (SLOs).
SLOs apply only to Managed Systems under active Managed Services or Co-Managed Services SOWs.

Nothing in this SG creates contractual SLO commitments beyond those expressly set forth in the MSA.

FOR THE AVOIDANCE OF DOUBT: The response times, resolution expectations, and service targets described in this Section 7 are operational guidelines only. They do not create enforceable service level agreements, do not entitle Client to service credits or financial remedies, and do not modify the warranty disclaimers or liability limitations in the MSA. Client’s sole remedy for Provider’s failure to meet SLO targets is to escalate concerns through the procedures described in Section 6.6 and to provide feedback during Technology Business Reviews.

7.2 SLO Resolution Expectations

Resolution times vary based on complexity, Vendor dependencies, system health, resource availability, and the nature of the issue. SLOs reflect reasonable efforts aligned to operational practices, not contractual obligations.

Resolution expectations may include:

Attempting initial remediation within the target window for the assigned severity
Engaging Third-Party Providers when the issue relates to a Vendor-supported system
Coordinating Client approvals for changes required to resolve issues
Providing status updates within reasonable intervals

Certain issues—such as complex Security Incidents, multi-Vendor dependencies, or environmental misconfigurations—may extend beyond typical resolution timelines.

7.3 SLO Suspension Factors

SLO applicability may be suspended when circumstances limit the Provider’s ability to perform work as expected. These conditions include, but are not limited to:

Systems failing to meet Minimum Requirements
Devices missing required security or management tooling
Unsupported Systems or legacy platforms
Client-declined remediations resulting in Risk Declinations
Upstream Vendor outages or failures
Insufficient or inaccurate documentation
Missing approvals from Authorized Approvers
Work performed outside of Included Services, such as on Third-Party Provider systems
The Client has outstanding past-due balances, which suspends SLO applicability as defined in the MSA.

When SLOs are suspended, the Provider will continue to use reasonable efforts to address the issue but cannot meet expected time targets.

7.4 Reporting & KPIs (High-Level)

The Provider may generate reports and Key Performance Indicators (“KPIs”) relevant to Managed Services or Security Services. Report content varies based on subscribed services and may include:

Ticket volume and categorization
Response or handling trends
Recurring issues or systemic patterns
Endpoint or infrastructure health indicators
Security events and blocked actions (Aggregated where appropriate)
Access licensing or consumption trends (High-Level)

Reports are typically reviewed during Technology Business Reviews or upon request where included as part of the subscribed Services.

7.5 Quality Assurance and Client Feedback

The Provider maintains internal quality assurance processes, including:

CORE Team review of after-hours or high-impact tickets
Sampling of closed tickets for accuracy and completeness
Internal escalation reviews for recurring issues
Coaching and feedback across CORE Team and TAC

Clients may provide feedback through ticket surveys, direct communication, or during TBRs. Feedback helps refine processes, identify patterns, and improve overall service quality.

8. Security Operations & Incident Handling

The operational practices in this section reflect how the Provider implements the authority defined in the MSA, but do not create additional contractual obligations.

During a Security Incident, the Client must identify an Incident Commander (IC) responsible for directing all involved parties. The Provider supports the IC with technical containment, remediation, and advisory information but does not act as Incident Commander unless explicitly requested and separately contracted.

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

8.1 Incident vs. Security Incident (Operational Distinctions)

The Provider distinguishes between:

Incidents

Operational issues that affect usability or performance of Managed Systems (e.g., outages, login issues, performance problems, application failures).

Security Incidents

Threats or indicators of malicious activity, such as:

Malware execution
Suspicious authentication patterns
Unauthorized access attempts
Indicators of compromise flagged by the SOC
Application or network whitelisting violations that signal potential threat activity

Security Incidents require different handling, escalation, and Client communication paths.

Licensing-Only Clients do not receive security incident handling, monitoring, SOC analysis, containment actions, or security notifications. Any vendor alerts received for licensed products are forwarded to the Client as a courtesy only.

All authority and role definitions for Security Incidents, including ALN’s supporting role and the Client’s designation of an Incident Commander, are governed by the MSA. This SG describes operational workflow only.

8.2 Monitoring & Alert Handling (NOC & SOC)

NOC (Network Operations Center)

Monitors device-generated operational alerts
Surfaces issues related to performance, health, or connectivity
Routes actionable alerts to CORE Team or TAC depending on timing
Does not communicate directly with the Client

SOC (Security Operations Center)

Monitors Security Events, behavioral anomalies, and Indicators of Compromise
Takes automated or manual containment actions where necessary
Conducts initial threat classification and analysis
Notifies the CORE Team for Client-facing communication
Does not communicate directly with the Client

NOC and SOC monitoring depends on functioning telemetry, meeting Minimum Requirements, and appropriate licensing.

Monitoring is limited to systems where Provider tooling is deployed, operational, and has not been disabled by the Client, 3PP, or Vendor. Provider does not monitor systems outside Managed Systems or those not fully onboarded.

8.3 SOC Workflow (Detect → Contain → Analyze → Notify CORE)

Security Event handling generally follows this operational sequence:

Detect
Behavioral analytics, threat intelligence, and automated detection systems identify suspicious activity.
Contain
SOC may isolate or restrict affected devices, sessions, or processes to prevent widespread impact.
Analyze
SOC analysts review telemetry, determine threat classification, and identify recommended actions.
**Notify
SOC sends findings to the CORE Team for Client communication.
CORE Team coordinates decision-making with the Client for further actions.

This workflow does not include digital forensics or post-breach investigative activities.

8.4 Security Incident Handling (Scope & Limitations)

Operational handling of a Security Incident includes:

Reviewing SOC findings
Coordinating containment or rollback actions
Documenting relevant details
Working with the Client to determine next steps
Recommending remediations to reduce recurrence

Limitations:

The Provider does not perform digital forensics
The Provider does not coordinate with law enforcement unless facilitated through a Third-Party Provider
The Provider does not act as an Incident Response retainer
Deep forensic or compliance breach notifications require Third-Party Providers or the Client’s legal counsel

The Provider may facilitate communication with Third-Party Providers upon Client request.

During active Security Incidents, the Provider may implement immediate containment or protective actions without prior Client approval when required to limit ongoing risk, consistent with the authority granted in the MSA. Restoration of normal operation may require explicit Client approval once the threat is addressed.

During a Security Incident, the Provider has authority to take immediate protective actions on Managed Systems as defined in the MSA. When third-party IR firms or insurance-appointed responders are engaged, the Provider will coordinate but does not assume investigative or command authority. Roles include:

Provider: containment, stabilization, telemetry collection, and support.
Third-Party IR (Client-appointed): investigation, forensics, threat analysis.
Client: final decision authority, communication to legal/regulatory bodies.

Where multiple service providers are engaged, the Client is responsible for identifying a lead Incident Commander (IC) for overall direction.

Provider may lock or isolate accounts, devices, or sessions when active risk is detected.

If an external Incident Response (IR) provider is engaged by the Client, the Provider will supply logs, telemetry, endpoint data, and relevant context as available. The external IR provider is responsible for investigation, root-cause analysis, and post-incident reporting. The Provider does not perform digital forensics unless a separate SOW is executed.

Cross-Reference Notice: The operational workflows described in this Section 8.4 implement the authority granted to Provider under MSA Section 6.6 (Emergency Maintenance and Protective Actions) and MSA Section 8.3 (Incident Handling). The legal rights, obligations, and limitations applicable to Security Incidents—including liability limitations, indemnification, and the disclaimer of threat prevention guarantees—are governed exclusively by the MSA. Nothing in this Services Guide expands Provider’s liability or creates additional remedies beyond those stated in the MSA.

8.5 Vulnerability Management Overview

8.5.1 Managed Services (Signal-Based Visibility)

For Clients receiving Managed Services, vulnerability visibility is based on patch signals, system health data, and surface-level indicators. This provides baseline awareness but is not a comprehensive vulnerability management program.

8.5.2 SHIELD Services (Ongoing Vulnerability Identification)

Clients receiving AlignSHIELD benefit from expanded vulnerability visibility.
While the Provider does not disclose tooling or cadence, this may include:

Continuous or periodic vulnerability identification
Exposure analysis across Managed Systems
Prioritization guidance

8.5.3 Risk-Based Remediation & Use of CVSS

Vulnerabilities are evaluated using risk-based methods, which may incorporate CVSS scoring, exploitability, system criticality, and Client business impact.

Recommendations may include:

Patching
Configuration adjustments
Compensating controls
Mitigation where remediation is not immediately feasible

8.5.4 Accepted Mitigations & Risk Registers

If the Client chooses not to remediate a vulnerability, the Provider may record the decision as:

A mitigation accepted by the Client
A Risk Declination
An entry in the Client’s risk register (where applicable under AlignASSURE)

These decisions may impact service scope and SLOs.

Vulnerability visibility is signal-based and not exhaustive. A lack of detected vulnerabilities does not imply that no vulnerabilities exist.

8.6 Limitations of Security Services

Security Services have operational boundaries, including:

No digital forensics
No deep packet inspection beyond aligned tooling
No law enforcement coordination unless through a Third-Party Provider
No certification or audit activities
No operational guarantee of threat prevention

Security measures reduce, but cannot eliminate, the risk of compromise.
Limitations are consistent with the MSA.

Risk Declinations may result in temporary suspension of affected services, required remediation activities, or additional fees when necessary to maintain security integrity, consistent with the MSA.

8.7 Telemetry & Logging Requirements (High-Level)

Security visibility relies on:

Functioning telemetry from Managed Systems
Supported operating systems and configurations
Stable network connectivity
Required security tooling being active and up to date
Cloud identity systems configured according to Minimum Requirements

Systems that cannot provide reliable or continuous telemetry may be reclassified as Unsupported Systems.

8.7.1 Logging Retention

The Provider maintains security and operational logs within the retention capabilities of its tooling and SIEM platforms. Typical SIEM retention is twelve (12) months, with certain immutable logs retained longer for audit integrity. The Provider does not guarantee availability of logs beyond these retention windows and does not provide custom log export or purge confirmations unless scoped in a SOW.

8.8 Client Participation in Security Incidents

During a Security Incident, the Client may be required to:

Approve containment or remediation actions
Provide user or business context
Assist with password resets, MFA re-registration, or account access changes
Temporarily remove or restrict access for impacted users
Coordinate with internal stakeholders for operational decisions

Delays in Client response may impact remediation timelines.

The Client must identify executive stakeholders for Security Incident response, including legal, compliance, and risk functions. The Provider coordinates with these stakeholders when directed by the Client but does not act as the Client’s representative to regulators, legal authorities, law enforcement, or insurers.

8.9 Approval/Unlock Process After Blocking Actions

When application or network whitelisting blocks an action, or when SOC containment isolates an endpoint:

The Client is notified through the CORE Team
The CORE Team explains the reason for the block, risk implications, and available options
The Client authorizes any required exception or unlock
The Provider applies the approved change or exception through the ticketing system

Unlocks or overrides follow the same change management rules outlined in Section 6.

8.10 Application & Network Whitelisting Workflow (Operational Overview)

SHIELD clients are protected by an application and network whitelisting security model that defaults to blocking unapproved executables, scripts, processes, network connections, and similar actions until they are reviewed and approved. This control helps prevent unauthorized software execution, lateral movement, malware activation, and misuse of development tools.

Whitelisting reduces attack surface but does not detect or prevent all malicious behavior. No whitelisting model is guaranteed to be error-free or threat-proof.

When a blocked action occurs, the user is presented with an on-screen prompt to request a review. The following workflow applies:

8.10.1 SOC Triage (Initial Review)

Upon a user request, the item is submitted to the Security Operations Center (SOC) for evaluation. The SOC examines the file or process using behavioral analysis, sandbox execution, integrity checks, business-rule validation, and comparison to known-malicious indicators. If the item is deemed safe and aligns with acceptable business use, SOC approves it and the user receives an on-screen confirmation that the item may now run.

8.10.2 CORE Team Review (Secondary Review)

If the SOC cannot approve an item—typically due to insufficient reputation, mixed indicators, or business-use uncertainty—the request is forwarded to the Client’s assigned CORE Team. The CORE Team evaluates legitimacy, risk, alignment with Client workflows, and potential security implications. If appropriate and safe, the CORE Team may approve the request.

8.10.3 Risk Declination Process (Client Decision Point)

If the CORE Team cannot approve a request safely, the item enters the Risk Declination workflow. The Technical Account Manager (TAM) contacts the Client’s Authorized Contact to explain potential risks and determine whether the Client wishes to authorize the exception. Approvals granted through Risk Declination are documented, tied to the specific Authorized Approver, and may affect Minimum Requirements or SLO applicability as defined in the MSA.

8.10.4 Developer and Power-User Considerations

Whitelisting review is a security control, not a code-review or software-quality audit. Developers and power users remain responsible for the safety, content, and behavior of their own code, scripts, and tools. Clients should plan and communicate upcoming software deployments or development tool needs in advance to minimize operational interruptions.

**8.10.5 Planning Expectations including Presentations, Webinars, and External Meetings

Clients should test and validate any new applications, browser-based tools, presentation platforms, webinar software, meeting plugins, or screen-sharing utilities in advance of business-critical events. Application and network whitelisting may block unapproved or unknown software, browser extensions, or embedded scripts until reviewed through the SOC/CORE workflow.

To avoid interruption during client meetings, sales presentations, interviews, webinars, vendor demonstrations, or similar events, Clients are strongly encouraged to perform a pre-event test or notify the Provider ahead of time if new tools will be used.

8.10.6 Software Updates, In-App Updaters & Built-In Profiles

Many software applications include built-in update buttons, auto-updaters, or background installers (e.g., accounting platforms, communications tools, productivity suites, and vertical-market applications). These updates often introduce new executables, modified binaries, or temporary installer components that may be blocked by application or network whitelisting until reviewed.

Clients should avoid clicking “Update,” “Upgrade,” or similar prompts without first confirming that the update is approved or submitting a ticket requesting review. Initiating an update that becomes blocked may render the application temporarily unusable until the SOC/CORE review process is complete.

For certain widely used business applications, the Provider maintains Built-In Profiles that automatically validate and approve vendor-supplied update packages. These profiles are updated on an ongoing basis as new versions are released and verified. Not all software has a Built-In Profile, and the Provider does not publish a list of such profiles for security reasons.

Clients should plan for updates in advance—particularly for payroll, accounting, and line-of-business applications where delayed updates could impact time-critical operations. When in doubt, Clients should submit a ticket before initiating an update.

9. Cloud & Consumption Services

9.1 Cloud Identity & Tenant Governance

The Provider assists in managing the Client’s cloud identity systems and associated tenant governance. Operational activities may include:

Administration of Entra ID and/or Google Cloud Identity
Enforcement of identity Minimum Requirements (MFA, Conditional Access, device compliance)
Lifecycle management for users, groups, and objects
Baseline configuration of cloud collaboration and communication systems
Coordination with Upstream Vendors on identity, licensing, or tenant-level changes

The Client remains responsible for approving identity-related changes, defining user access policies, and maintaining governance decisions that fall outside Included Services.

9.2 Cloud Resource Management (High-Level Best Practices)

The Provider may offer guidance and recommendations regarding resource allocation and configuration in the Client’s cloud environment. Operational best practices may include:

Organizing cloud resources for clarity and operational efficiency
Maintaining consistent naming and tagging conventions
Monitoring consumption signals and providing high-level insights
Recommending configuration adjustments for cost efficiency or operational reliability
Highlighting security posture considerations where appropriate

Cloud resource naming must align with the Provider’s standardized naming conventions defined in Section 3.3.6.

Cloud resource creation, architectural design, and complex infrastructure modifications may require additional scoping and may fall outside Included Services unless specified in the SOW.

9.3 Consumption Services – Billing and Behavior

Consumption Services are billed based on actual usage, as measured by Upstream Vendors such as cloud providers or telecom carriers. These services may include:

Cloud compute, storage, and networking
Serverless or event-driven functions
API calls and transaction-based services
Telecom minutes, SMS, or call routing
Other usage-based features governed by Vendor meters

Operationally:

Consumption is variable and may change with Client usage patterns
The Provider does not modify or control Vendor meters
Billing fluctuations are normal and may require Client review through the Provider or directly with the Vendor

Unexpected consumption behavior may require a separate investigation.

9.4 Client Responsibilities for Cloud Cost Governance

The Client maintains responsibility for:

Monitoring cloud cost trends
Setting internal budget thresholds
Approving changes that may increase consumption
Notifying the Provider of cost anomalies or unexpected growth
Reviewing and approving consumption summaries provided by the Provider

The Provider may provide guidance and recommendations, but cost governance decisions remain under Client control.

9.5 Access Licensing Administration

Access Licensing (as defined in the MSA) applies to cloud platforms, SaaS services, and managed identity systems.

9.5.1 Provider-Managed Licensing

When the Provider manages licensing on the Client’s behalf:

License changes are requested through the ticketing system
The Provider purchases, assigns, or removes licenses following authorization from an Authorized Approver
Licensing changes may take effect immediately or follow Vendor processing timelines
True-ups or minimum commitments follow Vendor rules, not Provider rules

9.5.2 Client-Managed Licensing

When the Client manages its own licensing:

The Client is responsible for obtaining, maintaining, and renewing licenses
The Provider performs administrative actions only after confirming valid licensing is active
Licensing lapses may limit functionality or result in Unsupported Systems

All Access Licensing commitments follow vendor-defined terms and are non-mitigatable for the full duration of the vendor commitment period, as outlined in the MSA.

9.6 Telecom & Cloud Voice Consumption (Cross-Reference to Section 13)

Telecom and cloud voice consumption, including call routing, toll-free usage, outbound minutes, and SMS traffic, follows the operational and billing behaviors described in Section 13.

Consumption charges originate from telecom carriers or cloud communications providers and may fluctuate based on usage or regulatory updates.

10. Governance, Risk & Compliance Services (Plan-Dependent Capabilities)

AlignASSURE delivers Governance, Risk & Compliance (GRC) support. However, certain GRC-related activities occur at all service pillars (AlignCORE, AlignSHIELD, AlignASSURE).
This section clarifies the operational scope of GRC activities and identifies which capabilities apply at each service tier.

Plan designations are shown as:

[CORE] – Included under AlignCORE
[SHIELD] – Included under AlignSHIELD
[ASSURE] – Included under AlignASSURE
(Unmarked) – Applies across all tiers where relevant

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

10.1 Overview of Governance, Risk & Compliance Support

GRC supports Clients in establishing, maintaining, and improving operational governance, security posture, and compliance-aligned practices.

Operational GRC activities may include:

Support in developing and maintaining key governance documents
Mapping security and IT controls to framework requirements
Supporting risk identification and remediation planning
Facilitating evidence collection and documentation workflows
Supporting strategic planning through Technology Business Reviews

Comprehensive GRC and framework alignment work is delivered under AlignASSURE.
AlignCORE and AlignSHIELD include more limited GRC-adjacent functions as described below.

10.2 Relationship Between Minimum Requirements and Framework-Specific Requirements

Minimum Requirements apply to all Managed Services and establish the foundational identity, endpoint, and network security controls necessary for effective service delivery.

Framework-specific requirements—whether based on security standards or compliance frameworks as identified in an applicable SOW:

Often exceed or differ from the Provider’s Minimum Requirements
May require additional controls, documentation, or operational processes
May introduce obligations that fall outside Included Services
May require separate remediation activities, projects, or program-level work delivered through AlignASSURE or a specifically defined SOW

Minimum Requirements do not replace or satisfy any external framework or regulatory obligations. Similarly, framework-specific controls do not waive or override the Provider’s Minimum Requirements unless they provide an equivalent or stronger safeguard as determined by the Provider.

Compliance responsibility remains with the Client, and alignment activities are delivered only as scoped in the applicable SOW.

10.3 Policy & Procedure Development Workflow [ASSURE]

Under AlignASSURE, the Provider supports the full lifecycle of policy and procedure creation through a structured workflow:

AI-Assisted Drafting: Baseline or framework-aligned drafts are produced.
Human Review: Provider personnel review AI outputs for structure and alignment.
Client Edits: The Client refines content based on business operations.
GRC Team Review: The Provider validates consistency and cross-policy alignment.
Finalization: The Client approves final versions.

Operational notes:

The Client is responsible for enforcement of all policies.
The Provider may supply tools or processes for policy attestation where applicable.
AlignCORE Clients may adopt the baseline cybersecurity policies listed in Section 3.7, but full policy lifecycle development is an ASSURE capability.

10.4 Security Risk Assessments

10.4.1 Managed Services (On Request) [CORE]

AlignCORE Clients may request high-level SRAs as separate engagements or projects. These SRAs generally:

Review basic configurations
Identify prominent risks
Provide recommended remediations
Do not constitute a formal compliance SRA

10.4.2 SHIELD Services (Ongoing Automated Inputs) [SHIELD]

AlignSHIELD provides ongoing automated visibility into vulnerabilities, suspicious behaviors, and security signals.
While useful for security insights, this visibility alone does not constitute a complete risk assessment unless scoped separately.

10.4.3 ASSURE (Human-Driven Assessments per Framework) [ASSURE]

AlignASSURE provides human-driven, framework-aligned SRAs which may include:

Review of governance documents, policies, and procedures
Control-level assessment against framework requirements
Gap identification and risk scoring
Recommendations and remediation planning
Risk register updates where applicable

Frequency and depth depend on the framework and SOW.

10.5 Evidence & Documentation Support (General, Non-Tool-Specific)

The Provider assists with evidence support across service tiers to the extent included in the Client’s SOW.

Evidence support may include:

Collecting configuration screenshots or system summaries
Identifying necessary governance artifacts
Coordinating with the CORE Team for operational documentation
Ensuring evidence is organized and aligned with framework expectations (ASSURE only)

The Client remains responsible for providing internal business documentation, HR artifacts, financial records, workflow explanations, and any content outside the Provider’s operational scope.

The Provider does not disclose internal tooling, scanning cadences, event thresholds, or proprietary workflows in this SG.

Evidence that must originate from HR, Finance, Executive, or operational business units remains the Client’s sole responsibility.

10.6 Compliance Scope & Limitations

The following limitations apply across all service tiers and are consistent with the MSA:

The Provider does not act as a certification body, auditor, or assessor
The Provider does not provide attestation services
The Provider does not guarantee certification or regulatory approval
While the Provider may operate as an RPO or advisory organization, the Provider does not perform certification assessments, formal audits, or decisions of conformity for any compliance framework.
The Provider may recommend Third-Party Providers for formal audits or advanced assessments
The Client is responsible for operationalizing and enforcing compliance controls, regardless of service tier

10.7 Technology Business Reviews (Cadence by Client Profile)

Technology Business Reviews (“TBRs”) are conducted to align technology and security strategy with the Client’s business objectives.
Depending on the Client’s service tier and size, reviews may occur:

Monthly
Quarterly
Semi-annually
Annually

Typical TBR content includes:

KPI and reporting review
Governance and policy progress (ASSURE)
Security posture review and recurring issues (SHIELD)
Strategic planning and roadmap development
Prioritization of remediation and lifecycle management

TBRs help maintain alignment between operational realities and long-term strategy.

**10.8 Security Communication Cadence

The Provider delivers ongoing security and operational communications, which may include:
• Monthly security newsletters
• Weekly short-form security awareness videos
• SOC/MDR summaries
• Security awareness training (SAT) reports
• Device lifecycle reports
• Governance or compliance milestone summaries

Where applicable, these reports are available through the Client Portal. Lifecycle reports should be reviewed monthly by Authorized Contacts. Communications are advisory and do not modify contractual obligations.

10.9 Cyber Liability Insurance Support

The Provider may assist the Client in gathering technical documentation, reports, evidence, or configuration details required for cyber liability insurance applications or renewals. Assistance is limited to technical facts regarding Managed Systems. The Provider does not complete insurance forms, interpret coverage terms, advise on legal or regulatory obligations, assess policy adequacy, or certify that Client meets any insurance requirements. All interpretations, representations, and attestations made on insurance applications are the sole responsibility of the Client.

11. Client Operational Responsibilities

The operational practices in this section reflect how the Provider implements the authority defined in the MSA, but do not create additional contractual obligations.

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

11.1 Authorized Contacts and Authorized Approvers

Client must maintain accurate lists of Authorized Contacts and Authorized Approvers. Only Authorized Approvers may request or approve configuration changes, access changes, security exceptions, or other operational actions requiring elevated authority. The Client is responsible for keeping these designations current and notifying the Provider of changes promptly.

11.2 Accuracy of Information

Client must provide complete, accurate, and timely information necessary for the Provider to deliver the Services, including system details, business requirements, change windows, user lists, and vendor information. Outdated or incomplete information may impact SLOs or limit the Provider’s ability to perform the Services.

11.3 Required Use of Ticketing and Change Management Processes

All support requests, incidents, and changes must be submitted through approved ticketing channels as described in Section 6. Side-band requests (direct messages, email to engineers, hallway conversations, etc.) are not permitted and do not constitute valid Requests.
Clients must follow the Change Management workflow described in Section 6.7 for any change with operational, financial, or security impact.

This subsection is a summary only—detailed processes appear in Section 6.

11.4 Hardware & Inventory Responsibilities

Client must maintain accurate asset inventories and ensure that hardware meets the Provider’s minimum specifications and requirements described in Section 3.4 and Section 10.1.
Clients are responsible for maintaining warranties, ensuring devices remain supported, and procuring spare hardware as required for operational continuity.

(Full operational detail remains in Sections 3.4 and 10.1; this subsection establishes client responsibility, not process.)

11.5 Facilities, Environmental, Power & Physical Requirements

Client must ensure that network, server, and infrastructure equipment is housed in appropriate physical environments and powered by stable, protected circuits, as outlined in Section 3.3.3.
This subsection serves as a pointer — full technical requirements are defined in Section 3.

11.6 Remote Work Responsibilities

Client must ensure remote workers maintain stable Internet connectivity, use Provider-approved security configurations, and follow identity and access management requirements. Provider does not manage or support home or public network infrastructure.

11.7 Data Protection, Backup & SaaS Backup Expectations

Unless the Client subscribes to a Managed Backup or SaaS Backup Service, Client is responsible for ensuring that required data is protected, retained, and backed up.
Provider may recommend solutions, but Client retains ultimate responsibility for their data unless a backup solution is expressly included in the SOW.

11.8 Third-Party Application Support Requirements

Client must provide administrative access, documentation, and vendor contact information for any business-critical application for which the Client requests support. Unsupported or undocumented applications may result in extended troubleshooting times or limited intervention.

11.9 Participation in Governance and Compliance Activities

Client must participate in Technology Business Reviews, security policy reviews, change approval workflows, and evidence collection activities where required.
Client remains responsible for policy enforcement and operational adherence to compliance frameworks unless explicitly contracted under AlignASSURE.

11.10 Domain, DNS & Email Authentication Responsibilities

Client must maintain ownership of all domain registrations. Provider does not register or own Client domains.
Client must provide an off-domain administrative email for domain records and ensure ICANN-required ownership information is accurate.
For Managed Services, DNS must be hosted on Provider-approved platforms. Marketing agencies, webmasters, and contractors may not modify DNS directly; changes must be submitted through the Provider.
Client must notify Provider before engaging any third-party service that sends email on behalf of the Client’s domain so that DNS and authentication entries (SPF, DKIM, DMARC) can be properly configured.

11.11 Browser, OS, and Device Standards

Client must ensure that end-user devices run Provider-supported operating systems and use modern, secure browsers (e.g., Chrome, Edge, Firefox).
Tools commonly associated with circumvention, anonymization, or illicit activity (e.g., Tor, torrenting software, P2P file-sharing tools) are not supported and may violate Provider security requirements.

11.12 Naming Convention Requirements

Client must adhere to Provider-defined naming conventions for identities, devices, groups, and cloud resources to maintain consistent management and automation. Specific naming standards are provided during onboarding or via the Client’s CORE team.
Failure to follow naming conventions may impair visibility, automation, and security baselines.

12. Provider Operational Responsibilities

Examples in this section are illustrative. Actual behavior may vary based on tools, environment signals, or business context.

12.1 Monitoring & Alert Handling

The Provider monitors supported systems and security tools in accordance with the applicable Service Tier and SOW. Alert triage is performed by the NOC and SOC as described in Section 8.
This subsection does not restate those workflows; it establishes that monitoring is a Provider responsibility and that alerts are processed using the operational models defined in Section 8.

12.2 Patch and Update Management

Where patch management is included in the applicable Service Tier, the Provider applies operating system, application, and security tool updates during the Client’s approved maintenance window.
Requirements, limitations, and minimum patching baselines are defined in Section 3.3.3 and Section 3.4.

12.3 Configuration and Hardening (Within Scope of SOW)

The Provider configures, hardens, and maintains Managed Systems in alignment with Provider best practices, baselines, and Minimum Requirements.
Security configuration and Zero Trust requirements are defined in Section 3.8; this subsection affirms that the Provider performs these tasks where included in the SOW.

12.4 Documentation Maintenance

The Provider maintains internal documentation necessary to deliver Services, including system configurations, network diagrams, security policies, and operational notes for Managed Systems.
Documentation provided to the Client appears in the Customer Portal or as defined by the applicable SOW.
Documentation responsibilities associated with governance or compliance activities are defined in Section 10.

12.5 Enforcement of Minimum Requirements

The Provider enforces Minimum Requirements to maintain stability, security, and supportability.
If Client systems fall out of compliance, the Provider may take the actions described in Sections 3.3, 3.4, and 3.8, including suspending SLOs, isolating systems, or requiring remediation prior to further support.

12.6 Change Implementation (Per Approved Requests)

The Provider implements approved changes in accordance with the Change Management process defined in Section 6.7.
This subsection establishes the Provider’s responsibility to perform approved changes, while Section 6 governs scope, authorization, and the approval workflow.

12.7 Emergency Actions

Where necessary to prevent imminent harm, active compromise, or material risk to Client systems, the Provider may take emergency protective actions consistent with Section 8.4 and the MSA.
Emergency actions are limited to containment, stabilization, or risk reduction and may require follow-up approval for permanent remediation.

12.8 Limitations of Services (“What the Provider Does Not Do”)

The Provider does not:

Perform work outside Included Services unless approved as Chargeable Services
Guarantee threat prevention, detection, or remediation outcomes
Support systems, software, or environments that do not meet Minimum Requirements
Provide digital forensics, incident response retainers, or law enforcement coordination, except through Third-Party Providers
Support custom, undocumented, or unsupported applications without required documentation

These limitations summarize operational boundaries; full limitation-of-liability terms are defined exclusively in the MSA.

Facilities, Construction, and Architectural Services

Provider does not provide architectural, construction, engineering, or physical facility
design services. While Provider may participate in planning discussions for office moves,
renovations, or construction projects where IT infrastructure is affected, Provider does not:

Produce architectural drawings, blueprints, or construction documents
Specify electrical, HVAC, or physical plant requirements beyond IT rack and cabling needs
Act as general contractor or construction manager
Certify compliance with building codes or ADA requirements

Clients undertaking construction or renovation projects should engage qualified architects,
engineers, and contractors. Provider’s role is limited to IT infrastructure planning and
coordination within separately scoped project SOWs.

13. Telecom & Voice Services

13.1 Overview of Telecom & Voice Services

Telecom and cloud voice services may include:

Number provisioning and management
Hosted telephony or cloud calling
IVR and call-flow configuration
Device setup and provisioning
Carrier coordination where required

Telecom services rely heavily on Upstream Vendors (carriers, VoIP platforms) whose performance is outside the Provider’s control.

13.2 Number Porting & Provisioning

Number porting and provisioning activities include:

Submitting port requests to carriers
Coordinating documentation and LOAs (Letters of Authorization)
Working with carriers through typical 7–30 day porting timelines
Scheduling cutovers during approved change windows
Adding/removing numbers within supported platforms

Porting delays may occur due to carrier validation issues, mismatched billing records, or Vendor-side processing timelines.

Number porting timelines, rejections, and activation delays are controlled exclusively by carriers and numbering authorities. Provider cannot guarantee port dates.

13.3 Device and Endpoint Configuration

The Provider configures supported telecom endpoints where included in the SOW.
Operational activities may include:

Provisioning desk phones or softphone clients
Assigning numbers and extensions
Configuring voicemail, greeting settings, and forwarding rules
Basic endpoint troubleshooting
Reprovisioning devices after firmware updates or reassignments
Training and reference materials may be provided from upstream carriers upon request.

Unsupported or legacy devices may require replacement or separate scoping.

13.4 Call Flow, IVR & Auto-Attendant Configuration

The Provider assists with call flow configuration, including:

Main menu structures
Business hour routing
Holiday schedules
Queue configurations
Auto-attendant prompts
Basic IVR branching

Complex IVR logic, conversational AI routing, or tightly integrated CRM workflows may require project-level scoping.

13.5 Telecom Consumption Billing Behavior

Telecom usage—including inbound/outbound minutes, SIP trunk usage, toll-free charges, and SMS traffic—is billed based on carrier records.

Operational reminders:

Consumption is variable and may fluctuate month-to-month
Provider does not modify carrier usage meters
Billing spikes may occur due to holiday volume, large conferences, or fraud attempts
Carriers may impose minimum usage or channel commitments

Clients should monitor statements and notify the Provider of anomalies.

13.6 Regulatory Fees, E911, and Surcharges

Telecom invoices may include:

FCC or local regulatory fees
E911 service fees
Number taxes or compliance surcharges
Universal service fund contributions

These charges originate from carriers and regulatory bodies.
The Provider does not control and cannot waive such fees.

13.7 Client Responsibilities

The Client is responsible for:

Maintaining correct address information for E911 records
Providing accurate business hour and holiday schedules
Supplying IVR audio or scripts
Ensuring consistent device network connectivity (QoS recommended but not enforced)
Maintaining valid licensing for telecom features
Coordinating internal communications for number port cutovers
Providing accurate and current account information from the losing carrier, including account numbers, PINs, and authorized user verification. Porting delays caused by inaccurate information are not Provider’s responsibility.
Compliance with carrier acceptable use policies for SMS/MMS services. Abuse of messaging services, including unsolicited marketing, mass texting to consumer numbers, or violation of TCPA/carrier guidelines, may result in immediate suspension of messaging capabilities by upstream carriers. Provider is not responsible for service disruption resulting from Client’s messaging practices.

Client delays may impact configuration timelines or porting dates.

13.8 Limitations (Upstream Vendor Behavior, Carrier Delays, etc.)

Telecom and cloud voice services depend heavily on Upstream Vendors.
Limitations may include:

Carrier outages or performance degradation
Delays due to Vendor-side ticket queues
Call quality issues caused by ISP or network congestion
Caller ID database propagation delays (3–30 days typical)
Regional telecom restrictions or routing issues

The Provider will coordinate with carriers as needed but cannot control their behavior or guarantee their timelines.

Carrier service levels, performance guarantees, and availability commitments do not flow down to the Provider.

14. Appendices

14.1 Included vs. Chargeable Services Matrix

This matrix provides a high-level reference to help Clients understand which activities are commonly Included Services and which typically require Chargeable Services. Specific inclusions and exclusions are defined in the SOW and the MSA.

Included Services (Examples)

Standard end-user support for Managed Systems
Patch management for supported operating systems
Identity and access administration (within SOW scope)
Network and infrastructure configuration changes
Baseline policy templates (CORE)
Application or network whitelisting enforcement (SHIELD)
Quarterly or periodic Technology Business Reviews

Chargeable Services (Examples)

Project work, migrations, and large-scale system changes
Work on Unsupported Systems or legacy platforms
Remediation of issues arising from undocumented Client changes
Specialized compliance documentation or audit preparation outside AlignASSURE
Complex IVR logic design
Advanced cloud architecture work
Forensics or breach investigation through Third-Party Providers

This matrix is a general guide and is not a substitute for the SOW.

Note: All onboarding and offboarding requirements, timelines, fees, and dependencies are governed by the MSA. The Services Guide provides operational context only and does not modify or replace the offboarding obligations defined in the MSA.

14.2 Shared Responsibility Matrix

This matrix illustrates operational responsibility between the Client and the Provider across major service domains.
It reinforces the shared responsibility model defined in the MSA.

Identity & Access

Provider: Configure identity baselines, manage access requests, enforce MFA/Conditional Access (where included).
Client: Approve changes, maintain Authorized Approvers, adhere to identity security practices.

Endpoints & Servers

Provider: Patch, configure, and monitor Managed Systems.
Client: Ensure devices remain powered, connected, and physically protected.

Networks & Infrastructure

Provider: Configure, update, and monitor supported devices.
Client: Maintain physical environments, ISP circuits, and required UPS power.

Security

Provider: SOC/NOC monitoring, whitelisting enforcement, containment actions.
Client: Approve remediations, enforce internal policies, maintain backup practices.

Compliance (When ASSURE Subscribed)

Provider: Policy drafting support, SRA execution, risk register management.
Client: Approve policies, enforce governance, maintain internal documentation.

14.3 RACI Matrix for Managed vs. Co-Managed Services

This matrix clarifies roles in environments where both the Client and Provider perform administrative actions.

Key:

R = Responsible (performs the work)
A = Accountable (final approval / ownership)
C = Consulted
I = Informed

Examples (High-Level):

Activity	Provider (Managed)	Client (Managed)	Provider (Co-Managed)	Client (Co-Managed)
Identity Admin	R/A	I	R	A
Network Changes	R/A	I	R	A (for approval)
Endpoint Patching	R/A	I	R/A	I
Application Adds	R	A	R	A
System Configuration	R/A	I	R	A (changes require tickets)
Whitelisting Exceptions	R	A	R	A

This model ensures clarity in environments where the Client retains some administrative control.

14.4 High-Level Onboarding Checklist

This checklist summarizes the typical onboarding sequence. Actual steps may vary based on the SOW and environment.

Kickoff & Requirements Review
- Meet with stakeholders
- Confirm scope, systems, and requirements
Environment Assessment
- Identity review
- Network and infrastructure validation
- Endpoint and tool eligibility check
Tooling Deployment
- Deployment to endpoints
- Identity integrations
- Network device enrollment
Documentation Collection
- Network details
- Application lists
- Contact lists and approval hierarchies
Baseline Configuration
- Identity security policies
- Endpoint security baselines
- Whitelisting learning mode (if applicable)
Go-Live & Monitoring Activation
- Begin NOC and SOC visibility
- Validate ticket flows
TBR Scheduling & Ongoing Coordination

14.5 High-Level KPI & Reporting Examples

KPIs and reports may vary by service tier, but commonly include:

Ticket volume, response times, and closure patterns
Endpoint health and compliance indicators
Repeated issues or systemic gaps
Whitelisting violations or SOC-triggered blocks
Licensing utilization trends
Consumption patterns for cloud or telecom services
Framework-aligned progress metrics (ASSURE)

Reports are typically reviewed during TBRs or upon request where included in the Client’s SOW.

14.6 Communication & Escalation Ladder

This ladder defines how communication flows during normal operations and elevated events.

End Users → CORE Team / TAC
CORE Team → TAM (Recurring issues, roadmap items, Risk Declinations)
CORE Team → SOC/NOC (Upstream signal collaboration)
TAM → Client Leadership (Strategic decisions, budget planning, compliance follow-up)
Provider Leadership → Client Leadership (Operational escalations, service-impacting events, major incidents)

Security Incidents follow the SOC → CORE → Client leadership path.

14.7 Revision History

This SG may be updated periodically. Revisions may include:

Clarifications
Expanded definitions
Additional examples
Updated Minimum Requirements
Updates to align with new frameworks, security practices, or platform behaviors

Clients are notified of revisions according to the communication method defined in the MSA or SOW.

Updates may occur due to vendor changes, security developments, regulatory requirements, or operational improvements.