HYPR Guard service agreement

This HYPR Guard Service Agreement governs HYPR Guard Services ordered from Observata Sweden AB (“Observata”). It forms part of the parties’ agreement where incorporated through the applicable Order Form or Governing Agreement. HYPR Guard is Observata’s Continuous Cyber Defense service.

1 Scope and incorporation

1.1 Application. This HYPR Guard Service Agreement (the “Service Agreement”) governs HYPR Guard Services ordered from Observata Sweden AB (“Observata”). HYPR Guard is Observata’s Continuous Cyber Defense service in the Security domain. It applies where the applicable Order Form identifies HYPR Guard.

1.2 Contract structure. The Governing Agreement controls general legal matters; the Order Form identifies the Protection Boundary, commercial commitment and transaction-specific terms; this Service Agreement controls HYPR Guard service-family and commercial mechanics; and any applicable Service Description or expressly incorporated operational specification controls the standard operational content identified for the ordered Service.

1.3 Support and data protection. The Support and Operational Services Policy applies to HYPR Guard. The applicable DPA applies where Observata processes Personal Data on Customer’s behalf. A security event or security incident is not necessarily a Personal Data Breach; Personal Data Breach obligations remain governed by the DPA.

1.4 No implied expansion. HYPR Guard is technology-enabled and not technology-defined. The presence of a data source, integration, security product or accessible system does not by itself place that item within the Protection Scope or expand Observata’s authority.

2 Defined service terms

2.1 Protected Asset. “Protected Asset” means a digital resource included within the agreed HYPR Guard Protection Scope and recorded as an active service object for protection, onboarding, service management, reporting, evidence, improvement and commercial consumption.

2.2 Resource Class. “Resource Class” means one of the HYPR Guard resource categories used to classify a Protected Asset: End User Computing, Infrastructure, Applications & Data, Platform, or Security.

2.3 Protection Scope. “Protection Scope” means the set of active Protected Assets, relevant dependencies, data and signal sources, coverage, contacts and agreed exclusions recorded for the Customer.

2.4 Protection Boundary. “Protection Boundary” means the agreed extent of HYPR Guard protection around the Protection Scope: Core, Workforce or Enterprise.

2.5 Operational Requirements. “Operational Requirements” means the Customer-specific operating parameters for HYPR Guard, including relevant coverage, escalation, response authority, procedures, contacts, exclusions and other agreed operating conditions.

2.6 Security Event. “Security Event” means activity, a signal or another condition identified within the Protection Scope that may require security triage, analysis or investigation.

2.7 Security Incident. “Security Incident” means a Security Event or related set of events assessed within HYPR Guard as requiring material investigation, escalation, response coordination or response action.

2.8 Response Authority Record. “Response Authority Record” means the traceable record of the operational actions Customer authorises Observata to perform, including applicable systems, conditions, escalation rules, approvals and restrictions.

3 HYPR Guard service model

3.1 Continuous Cyber Defense. HYPR Guard operates through the lifecycle Protect → Detect → Understand → Respond → Learn → Improve. Observata uses the lifecycle to establish and maintain agreed coverage, identify relevant activity, investigate with security and operational context, coordinate or perform authorised response, learn from events and improve the Service.

3.2 Service nature. The lifecycle describes service activities and continuous responsibility. It is not a guarantee that security incidents will be prevented, that every threat will be detected, that cyber risk will be eliminated or that every investigation will result in a conclusive determination.

3.3 Delivery model. HYPR Guard is delivered through a Local Security Advisor and Central Operations. The Local Security Advisor coordinates Customer context, governance, priorities, service ownership, improvement and evolution. Central Operations provides the agreed operational security capability, including continuous monitoring, detection, investigation, escalation, tuning and authorised response activities.

3.4 Service ownership. Observata owns the HYPR Guard customer relationship, service governance, defined service outcomes and service evolution. Observata may use specialist personnel or Third-Party Services within Central Operations without transferring ownership of the HYPR Guard Service.

4 Protected Assets and Protection Scope

4.1 Scope register. Observata will maintain a reasonable service record of active Protected Assets and the Protection Scope through the Customer Portal or another traceable service record. The record may identify Resource Class, relevant dependencies, signal sources, coverage, contacts and agreed exclusions.

4.2 Classification. Each Protected Asset is assigned to exactly one Resource Class according to its primary protected function. Resource Class identifies what kind of resource is included and does not by itself determine the extent of protection.

4.3 Counting principle. The protected resource is counted, not each technical mechanism used to protect or observe it. Agents, integrations, dashboards, indices, data streams, logs, policies, rules, connectors and API calls are not separate Protected Assets merely because they exist.

4.4 Scope activation. A resource becomes an active Protected Asset when it is agreed for inclusion, sufficiently onboarded for the applicable service activities and recorded as active in the Protection Scope. Inclusion does not imply that every possible signal, control or response action is available for that asset.

4.5 Scope changes. Customer may request additions, removals or other reasonable changes through the Customer Portal, service desk, Local Security Advisor workflow or another traceable channel accepted by Observata. Observata may require technical validation and clarification of coverage, dependencies or authority before a requested change becomes effective.

5 Protection Boundaries

5.1 Core. Core extends HYPR Guard protection around the agreed Protected Assets themselves. It is asset-focused and may use relevant security and operational context required to protect those assets.

5.2 Workforce. Workforce extends the Protection Scope around Protected Assets to relevant people and identities, including accounts, privileges, access and human-risk context associated with the protected environment.

5.3 Enterprise. Enterprise extends protection across relationships and activity spanning Protected Assets, identities and security domains to support cross-domain context, attack-chain understanding and coordinated response.

5.4 Boundary principle. Core, Workforce and Enterprise describe increasing breadth of protection. They are not quality grades or fixed feature bundles and do not promise that all possible telemetry, integrations, controls or response actions are available. Actual coverage is determined by the Protection Scope and Operational Requirements.

5.5 Boundary change. A change of Protection Boundary changes the ordered Service scope and commercial treatment and requires an amended Order Form or another commercial change accepted under the Governing Agreement.

6 Continuous security operations and service levels

6.1 24/7 operations coverage. Central Operations provides continuous HYPR Guard monitoring, detection, security-event triage and incident-handling coverage 24 hours per day, 7 days per week, 365 days per year for the active Protection Scope.

6.2 Customer-initiated support. Technical Support is available 24/7/365 in accordance with the Support and Operational Services Policy. Its severity classifications and Target Initial Response commitments apply to properly logged Customer Support Requests.

6.3 Service-generated events. Security Events identified through HYPR Guard monitoring do not require a Customer Support Request to enter operational triage. Central Operations will assess relevant detected activity in accordance with HYPR Guard operating procedures, the Protection Scope and the applicable Response Authority Record.

6.4 Investigation and escalation. Observata will use commercially reasonable efforts to commence and progress investigation of relevant Security Incidents, engage appropriate resources and escalate according to the applicable Operational Requirements. No fixed investigation-completion, containment or resolution time applies unless expressly stated in the Order Form.

6.5 Operational Support. Local Security Advisor, service governance, planned improvement and other non-incident Operational Support activities are provided during Business Hours under the Support and Operational Services Policy unless the Order Form expressly states another coverage window.

6.6 No resolution guarantee. Target Initial Response and continuous operations coverage are commitments to availability of the relevant function, engagement and operational handling. They are not guarantees of prevention, containment, restoration, eradication, recovery or permanent resolution.

7 Response authority and security accountability

7.1 Customer accountability. Customer retains enterprise security accountability, including overall risk ownership and acceptance, strategic security policy, regulatory accountability, business-impact decisions and ultimate enterprise authority. Observata is responsible for the HYPR Guard service outcomes expressly assigned to it.

7.2 Authority framework. HYPR Guard uses the following response-authority framework: Observe; Investigate; Recommend; Contain with approval; and Pre-authorised containment. Authority may differ by Protected Asset, system, action or scenario.

7.3 Baseline authority. Unless the Response Authority Record expressly grants greater authority, Observata may Observe, Investigate and Recommend within the Protection Scope but will not perform containment or another materially interventionist response action without Customer approval.

7.4 Contain with approval. Where this authority applies, Observata may prepare and coordinate a containment action but must obtain approval from an authorised Customer representative before executing the action, except where another expressly recorded emergency procedure applies.

7.5 Pre-authorised containment. Where this authority applies, Observata may perform the specifically pre-authorised containment actions without obtaining case-by-case approval, but only within the systems, conditions, thresholds, procedures and restrictions recorded in the Response Authority Record.

7.6 Authority record and changes. The initial authority profile will be established through the Order Form, onboarding or another traceable record approved by an Authorised Representative. An Authorised Representative may subsequently change operational authority through a traceable channel accepted by Observata. Such an instruction changes operational authority only and does not amend liability, pricing or other legal terms unless the applicable commercial-change process is also completed.

7.7 Restricted actions. Actions such as isolating endpoints, disabling accounts, blocking traffic, quarantining resources, modifying security controls or automating remediation require authority appropriate to the action. Observata does not assume unrestricted control over Customer systems.

8 Operational Requirements

8.1 Customer-specific record. Observata and Customer will establish the Operational Requirements for the ordered Service during contracting or onboarding. The record should be sufficiently clear to support operational delivery and may be maintained in the Order Form, Customer Portal, service documentation or another traceable operational record.

8.2 Required parameters. Operational Requirements may include coverage assumptions, escalation paths, authorised contacts, response authority, communication procedures, Customer dependencies, relevant maintenance or change processes, priority services, exclusions and other operating conditions reasonably required for the Protection Scope.

8.3 Operational changes. Operational Requirements may be adjusted through normal service governance where the change does not materially alter the ordered Protection Boundary, commercial commitment, legal allocation of risk or standard Service scope. A material change requires the applicable commercial or contractual change process.

8.4 Conflicts. If an operational record conflicts with the Order Form, this Service Agreement or the Governing Agreement on a legal or commercial matter, the applicable contractual precedence rules govern.

9 Credits and commercial mechanics

9.1 Credit basis. Where the Order Form uses Observata Credit Units or equivalent Credits for HYPR Guard, monthly Credit consumption is based on the active Protected Assets, their Resource Classes, the ordered Protection Boundary and the applicable Credit rate.

9.2 Applicable rates. Credit rates are not fixed by this Service Agreement. The applicable Observata Pricing determines the standard Credit consumption rate for each Resource Class and Protection Boundary. Customer-specific commercial commitments, pricing or deviations stated in the Order Form apply in accordance with the Governing Agreement.

9.3 Monthly consumption. Each active Protected Asset consumes Credits for each month in which it is active. Activation or deactivation during a month is prorated according to the number of calendar days during which the Protected Asset is active unless the Order Form expressly states another measurement method.

9.4 Reclassification. Observata may correct a Protected Asset classification where the protected resource or its primary function has been incorrectly classified. A correction applies prospectively unless the prior classification resulted from a manifest error or materially incorrect information supplied by Customer.

9.5 Consumption records. Observata may use the Customer Portal, Protection Scope, platform records and other reasonable service records to determine active Protected Assets, classification and Credit consumption. Observata will provide reasonable visibility of consumption and remaining entitlement.

9.6 No fixed asset commitment. The number and composition of Protected Assets may change during the commitment period without amending the Order Form, provided that the change remains within the ordered Protection Boundary, applicable Operational Requirements and available commercial entitlement.

9.7 Credit shortfall. Customer must maintain sufficient Credit entitlement for the active Protection Scope. General Credit validity, carry-over, pull-forward, shortfall, cure, expiry, refund and suspension mechanics are governed by the Governing Agreement except to the extent the Order Form expressly provides otherwise.

10 Service onboarding and change

10.1 Onboarding. HYPR Guard onboarding establishes the initial Protection Scope, Resource Classifications, relevant integrations and signal sources, Operational Requirements, contacts, governance and Response Authority Record required to activate the Service.

10.2 Customer readiness. Customer will provide timely information, access, licences, permissions, contacts, approvals and technical prerequisites reasonably required for onboarding and continued delivery.

10.3 Activation sequence. Protected Assets may be activated progressively as prerequisites and coverage become available. A Protected Asset does not become commercially active merely because it has been identified during discovery.

10.4 Material service change. A material expansion of the Protection Scope, change of Protection Boundary, materially different Operational Requirement or bespoke capability outside the standard HYPR Guard model may require additional Credits, a Project Specification, an amended Order Form or another agreed commercial arrangement.

11 Governance, evidence and improvement

11.1 Local Security Advisor. The Local Security Advisor coordinates service reviews, Customer context, priorities, escalation paths, Protection Scope governance, improvement planning, service evolution and relevant specialist coordination.

11.2 Service reviews. The parties will conduct recurring service reviews at a reasonable cadence. Reviews may cover Protection Scope, coverage, material events and incidents, operational trends, response authority, risks, improvement actions, Credit consumption and planned changes.

11.3 Evidence chain. HYPR Guard is operated to maintain a reasonable evidence chain across Protection Scope → Coverage → Signals → Investigation → Response → Improvement → Verified Change. Where an element is absent, incomplete or not yet verified, Observata will not represent it as completed evidence.

11.4 Continuous improvement. Observata may tune detections, coverage, procedures, integrations and operational priorities within the ordered scope based on service evidence, security developments and lessons learned, subject to applicable authority and change controls.

11.5 Reporting boundary. Reports and evidence describe the Service and activity within the agreed Protection Scope. They do not constitute a certification that Customer is secure, compliant, breach-free or protected against all threats.

12 Customer responsibilities

12.1 Cooperation. Customer will provide timely and accurate information, access, permissions, logs, contacts, approvals and reasonable cooperation required for HYPR Guard.

12.2 Enterprise decisions. Customer remains responsible for enterprise-level security policy, risk acceptance, regulatory decisions, business-continuity decisions and other matters outside Observata’s expressly assigned Service responsibility.

12.3 Supported environment. Customer will maintain supported systems, licences, entitlements, connectivity and technical prerequisites for Customer-provided components unless Observata expressly assumes that responsibility.

12.4 Accurate scope information. Customer will reasonably cooperate in maintaining accurate information about Protected Assets, dependencies, authorised contacts and operational restrictions and will notify Observata of material changes that may affect protection or response.

12.5 Authorised representatives. Customer will designate representatives authorised to approve Operational Requirements, Response Authority Records, material operational decisions and other Customer instructions required for the Service.

13 Technology, third parties and automation

13.1 Technology principle. Observata may use relevant security, identity, network, cloud, observability and other technologies to deliver HYPR Guard. No individual technology, vendor product or integration defines the Service.

13.2 Customer technology. Where HYPR Guard relies on Customer-provided technology, Customer will maintain required licences, support rights, configurations and access unless the Order Form assigns that responsibility to Observata.

13.3 Third-Party Services. Observata may use Third-Party Services or specialist providers in delivering Central Operations. Their product behaviour and upstream service performance remain subject to the relevant provider, while Observata remains responsible for its own express commitments under the parties’ agreement.

13.4 Integration limits. Compatibility, available telemetry, control functions and response capability depend on the relevant technology and Customer environment. Observata does not warrant universal integration or control capability.

13.5 AI and automation. AI and automation may support analysis, prioritisation and operational speed but do not remove the requirement for governed authority and human accountability. Any automated response action must remain within the applicable Response Authority Record and agreed controls.

14 Security service boundaries

14.1 No absolute security guarantee. HYPR Guard does not guarantee prevention of breaches, elimination of cyber risk, detection of every threat or successful containment of every Security Incident.

14.2 No unrestricted authority. HYPR Guard does not grant Observata unrestricted operational or enterprise authority. Observata may act only within the Protection Scope, Operational Requirements and applicable Response Authority Record.

14.3 Not a single technology service. HYPR Guard is not defined as an EDR service, SIEM service, Elastic Security product or other single-technology service, even where such technologies contribute to delivery.

14.4 Existing capabilities. HYPR Guard may work with and complement Customer’s existing security teams, SOC, MDR provider and technologies. It does not by itself require replacement of those capabilities unless the parties expressly agree a transition.

14.5 HYPR SecOps. HYPR SecOps is outside the scope of this Service Agreement. Nothing in this Service Agreement incorporates, retires, replaces or predicts any HYPR SecOps service.

15 Term and document relationship

15.1 General Credit mechanics. The Governing Agreement controls general Credit validity, carry-over, pull-forward, expiry, refund treatment and other general Credit mechanics except where this Service Agreement expressly defines HYPR Guard consumption mechanics.

15.2 Version governance. A later version of this Service Agreement applies only to a new Order, Renewal Term or express amendment under the Governing Agreement. The version applicable to an active fixed term continues for that term unless the parties expressly agree otherwise.

15.3 Published terms. The current standard version of this Service Agreement is made available through Observata’s Legal Center. Historical versions remain retrievable where required for active Customer terms.

15.4 Precedence. If documents conflict, the precedence rules in the Governing Agreement apply. Functionally, the Order Form controls transaction-specific commercial terms and expressly agreed Operational Requirements; this Service Agreement controls HYPR Guard service-family and consumption mechanics; an applicable Service Description controls standard operational content where incorporated; the Support and Operational Services Policy controls reusable support mechanics; and the Governing Agreement controls general legal matters.