Handling of Security Incidents and Vulnerabilities¶
Who notifies whom of Product incidents and vulnerabilities and within what time limits; security advisories; contacts
Version: 1.0.0
Classification: Confidential
Owner: Managing Director, MAZEVAULT s.r.o.
Last Updated: 2026-05-01
Review Cycle: Annual and upon any change to the contractual documentation
1. Starting Points¶
- The Product is operated by the Customer in its own infrastructure. The Provider has no access to the Customer's environment and neither detects nor resolves incidents in it — detection, containment and recovery in the Customer's environment are the responsibility of the Customer (or of the Partner as operator).
- The Provider is responsible for defects and vulnerabilities of the Product: their assessment, mitigating measures, remediation and informing the Partner.
- The Customer's sole contact for technical support is the Partner (SLA Art. 1.2, 3.1). The Provider communicates with the Partner; direct involvement of the Provider may be agreed for a specific incident.
- Statutory reporting obligations towards NÚKIB, the CNB or the ÚOOÚ are fulfilled by the Customer. The Provider fulfils its own statutory obligations only in relation to its own systems (license server) and as a software manufacturer.
The terms Incident, Security Incident, Ticket and Upstream Escalation have the meaning given in the SLA.
2. Classification (SLA Art. 5)¶
| Priority | Criteria (abbreviated) |
|---|---|
| P1 – Critical | Complete unavailability of the Product in production without a workaround; confirmed or reasonably suspected Security Incident; compromise of Security Assets; breach of data integrity; CA unavailability preventing certificate issuance or validation |
| P2 – High | Key function substantially impaired without a reasonable workaround; failure of audit logging, MFA or > 25 % of agents; potential Security Incident under investigation |
| P3 – Medium | Non-critical function impaired with a workaround |
| P4 – Low | Cosmetic defect, question, feature request |
The priority is proposed by the Customer; the Partner may change it with justification after diagnosis; the change must not delay the response to a possible Security Incident (SLA Art. 5.1).
3. Notification Chain and Time Limits¶
| Step | Who → whom | Time limit | Contractual basis |
|---|---|---|---|
| The Customer discovers an incident or a vulnerability of the Product | Customer → Partner and info@mazevault.com | Immediately, no later than 72 hours; no disclosure until remediation (responsible disclosure) | License Terms Art. XI |
| Partner's response to the Ticket | Partner → Customer | According to the license variant (e.g. P1: 1 business day Standard / 4 h Extended / 60 min Premium); ongoing status updates | SLA Art. 7 and tables |
| Upstream escalation of a Product defect | Partner → Provider | P1 without a path to resolution after 2 hours | SLA Art. 12.1 |
| Provider's response to a complete escalation | Provider → Partner | P1: 1 hour; P2: 4 hours; P3: 1 business day; P4: 3 business days; P1 status updates every 60 min | SLA Art. 8 and table |
| Actively exploited vulnerability of the Product | Provider → Partner | Immediate initiation of emergency response; advance warning and mitigating measures available within 4 hours | SLA Art. 10.2 |
| Release of a security patch (target) | Provider | Critical (CVSS ≥ 9.0 or access to Security Assets): within 48 h; high: within 7 days; medium/low: according to the release cycle, within 90 days | SLA patch table |
| Deployment of the patch | Customer (operator) | Critical: within 7 days of release; high: within 30 days; other: nearest maintenance window, max. 90 days; stricter statutory time limits take precedence | License Terms Art. V; SLA patch table |
| Personal data breach | Partner → Customer; Provider → Partner and Customer (only for data under DPA Art. 2.3) | Without undue delay, no later than 24 hours from detection; supplementary information progressively | DPA Art. 7 |
Patch release time limits are a preliminary target subject to professional effort; if they cannot be met, the Provider communicates the reasons, alternative measures and an updated estimate (SLA Art. 10.2). The SLA does not establish any entitlement to a service credit (SLA Art. 12.3).
4. What the Provider Provides during an Incident¶
- product triage, preliminary root-cause assessment, proposal of a diagnostic step, workaround or remediation plan (SLA Art. 8.1),
- mitigating measures where the cause is not known (SLA Art. 8.1),
- a security advisory for a confirmed vulnerability: description, affected versions, severity (CVSS), mitigation, fixed version — to the Partner and to Customers with an active license; for PoC licenses in the form of a notice (List of Required Software Art. 5),
- information on the cause and remediation of the Product defect as a basis for the Customer's report to the supervisory authority — through the Partner,
- preservation of its own evidence relating to the Product defect.
Access credentials, private keys, passwords or other secrets are not to be included in the Ticket or the escalation; logs are handed over in minimised form (SLA Art. 6.2, 11.1).
5. Product Support for Incident Handling at the Customer¶
The Product provides the Customer with features usable in its own incident response — implementation described in the Security section:
- integrity-protected audit log (hash chaining) with export to SIEM (Audit Logging, SIEM Rules),
- certificate revocation, rotation of keys and secrets (Certificate Lifecycle),
- session management and access revocation (Authentication).
Retention and long-term archiving of audit records are ensured by the Customer in its own SIEM/archive (SLA Art. 11 and the audit records table).
6. Exclusions (SLA Art. 9.3)¶
Response and communication commitments do not apply to the extent that the incident is caused by an unsupported configuration, unauthorised modification of the Product, an unapplied security patch, third-party infrastructure or service, breach of the documentation, force majeure or failure to provide cooperation. An exclusion does not relieve the Partner or the Provider of the obligation to accept the incident, perform reasonable triage and communicate the findings.
7. Contacts¶
| Purpose | Contact |
|---|---|
| Reporting incidents and vulnerabilities to the Provider | info@mazevault.com (the Provider's sole communication e-mail) |
| Incident reporting by the Customer, technical support | Partner — channel and contacts according to the Order (SLA Art. 6.1, 13) |
| Management escalation | Partner → info@mazevault.com; acknowledgement within 2 business hours (SLA Art. 12.2) |