Why a self-hosted team chat channel matters for DORA crisis communication
Consider a financial entity whose core banking platform fails during a major ICT incident. The same outage can take down the cloud chat service that its incident team uses to coordinate, and the staff who must inform clients and counterparts are left without a shared channel. DORA Article 14 requires crisis communication plans that enable responsible disclosure of major ICT-related incidents to clients, counterparts and, as appropriate, the public. Article 11 requires an ICT business continuity policy with response and recovery plans that are tested at least yearly and after substantive changes. Both obligations assume a communication channel that still works while the incident is ongoing. Regulation (EU) 2022/2554 is directly applicable and has applied since 17 January 2025, so it binds in-scope entities without national transposition. DORA does not certify products. Your evidence will be that the channel was designed, tested and governed for crisis use, not that a vendor holds a DORA label.
Self-hosting can help, but only conditionally. The benefit depends on whether the chat platform, its database, file storage, identity provider, push notification path and DNS are independent of the systems that may fail. A self-hosted Mattermost or Rocket.Chat instance that authenticates through the same directory and runs on the same cluster as the failing core system gives you little extra resilience. Start by mapping every dependency of the crisis channel and deciding which ones must survive a severe disruption. Confirm with the vendor which deployment patterns they support for your required availability, and whether high availability features are included in the edition you plan to buy. Then decide who is named under Article 14(3) to run the communication strategy, and which staff are only informed rather than involved in response.
Test the channel as part of the crisis plan, not as a separate IT project. Schedule exercises that assume the primary identity provider or primary network segment is unavailable, and record what staff can still reach. Keep an offline contact procedure for the case where chat itself is down. Document each test, the gaps it exposed and the fixes applied, because those records are the evidence an auditor or competent authority will ask for. Ask your implementation partner to show how the test environment mirrors production dependencies, how crisis channels and their audit logs are preserved, and how upgrades are scheduled so that the platform does not drift out of support during an incident window.
Which DORA requirements the chat channel must satisfy and how to configure it
This table maps each DORA article in scope for crisis communication to what the chat function must do and how to configure it in a self-hosted platform. Read it as a checklist for the chat design, then confirm each configuration with your compliance lead and your platform partner. The main takeaway is that the channel itself must stay reachable during an incident, and that its settings must separate responders from people who only need to be informed.
| Requirement | What the chat function must do | How to configure it |
|---|---|---|
| Article 14(1): responsible disclosure of major ICT incidents | Let the crisis team tell clients, counterparts and, where appropriate, the public in a controlled and consistent way while the incident is open | Keep a dedicated incident space with a fixed owner, approved message templates and a log of what was sent to external parties. External sharing should go through a separate channel, not general staff rooms |
| Article 14(2): differentiated staff communication | Separate staff who respond and recover from staff who only need updates, and give each group the messages it needs | Create a responder channel with explicit membership, and a read-only broadcast channel for everyone else. Use role-based membership and directory group sync so access follows roles, not manual invitations |
| Article 14(3): named communication owner | Name at least one person to run the communication strategy and the public and media function during an ICT incident | Assign the owner as a channel moderator with posting rights in the external-facing channel. Record the named role in the runbook and confirm a deputy can post if the owner is unavailable |
| Article 11(1) and (2): continuity and crisis communication actions | Keep the crisis channel usable when the production network, identity provider or main chat cluster is degraded | Run the chat on infrastructure that is independent of the affected systems where feasible. Confirm with the vendor which high availability features your edition includes, and document a fallback channel for the case that chat itself is down |
| Article 11(6): yearly testing including crisis communication | Prove at least once a year, and after substantive system changes, that crisis messages reach the right people through the chat channel | Schedule drills that use the responder and broadcast channels, include a simulated loss of the primary chat service, and record delivery, time to first message and gaps found. Repeat after upgrades or identity changes |
| Article 11(7): internal and external crisis communication procedures | Document who communicates what, to whom and through which channel, for both internal and external audiences | Write the procedure as a runbook linked from the chat tool. Include channel names, escalation paths, approval steps before external messages and the contact list used when chat is unavailable |
| Article 11(8): readily accessible activity records | Keep records of activity before and during a disruption that can be retrieved quickly once plans are activated | Set retention on incident channels so they are not deleted by default policies, enable audit logging for channel membership and edits, and schedule regular exports of incident channels to a separate store. Confirm which audit and export features your edition provides |
Which open-source chat platforms fit a DORA crisis channel
A crisis channel has to run during the incident it serves, so the platform's licensing, clustering model, upgrade cadence and federation settings matter as much as its feature list. The three options below differ in each of these, and the paid-edition questions apply to all of them.
Mattermost: binaries, database and shared storage
Mattermost compiled releases are MIT licensed and run as a single Linux binary with PostgreSQL as the database. High availability needs redundant application servers, redundant database servers and redundant load balancers, plus shared file storage on S3, an S3-compatible service or NAS mounted on every node, because local file storage risks corrupting files. Clustering sits on the Enterprise and Enterprise Advanced tiers, so confirm which tier your crisis design requires against the current pricing page before you size the deployment.
Rocket.Chat: MIT core, enterprise directories
Rocket.Chat code is MIT licensed, but the apps/meteor/ee and ee directories sit under a separate enterprise license, so confirm which components your crisis channel depends on. It needs MongoDB 8.0 or later running as a replica set, with three members strongly recommended for high availability. Multi-instance and microservice designs, along with tamper-evident audit trails and automated failover, appear on paid plans, so price those editions into the design from the start.
Rocket.Chat: support windows force upgrades
Standard Rocket.Chat releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security fixes, cloud services such as the push notification gateway stop working, and the official mobile and desktop clients may stop connecting. For a crisis channel, that means a scheduled upgrade calendar and a tested rollback are part of the operating model, not an optional task.
Matrix Synapse: AGPL-3.0 and federation policy
Synapse, the Matrix homeserver maintained by Element, is licensed under AGPL-3.0, which carries source-availability obligations for modified network services and should be reviewed by your legal team. Matrix federation lets your organization exchange messages with other homeservers, so a crisis channel needs a written federation policy that names trusted domains, or federation is disabled. Confirm the homeserver scaling and clients you plan to use before committing.
Confirm edition features before procurement
SSO, directory sync, high availability, air-gapped operation, audit trails and FIPS compliance depend on the edition you choose, and vendors change their plan tables. Ask each vendor, in writing, which features a DORA crisis channel needs are included in the edition you quote, and whether those features are available in your deployment model. Treat the current plan documentation as the source of truth, not any comparison article, including this one.
How the crisis channel is built and tested in sequence
This sequence turns a chat platform into a crisis communication channel that the business impact analysis has tied to specific critical functions. Each step produces a record that an internal auditor or competent authority can review, from the dependency map through to the yearly test results.
Map the chat dependency in the business impact analysis
The continuity or risk team lists the critical or important functions under Article 11 and records which of them depend on chat to coordinate response, recovery and crisis communication. Operations, business owners and the ICT service owners review the list together, because they know which teams would lose their working channel if the primary ICT services failed. The output is a dependency register that names the chat service, its users, and the functions it supports. The step is done when each named function has an owner who has signed off the dependency.
Deploy chat outside the primary ICT services
The platform team places the chat service on infrastructure that does not share the identity provider, network segment, database cluster or storage with the systems it is meant to help recover. Mattermost and Rocket.Chat both depend on a database and shared file storage, so the team confirms those dependencies are separately hosted and that a failure in the primary data center does not take the chat down with it. Access paths for responders, including mobile and out-of-band login, are documented. The step is complete when a dependency diagram shows no shared single point of failure with the protected services, and the team can reach the chat when the primary environment is unavailable.
Configure incident channels and responder roles
The crisis management function creates standing incident channels for major ICT-related incidents, with membership rules that separate staff who manage response and recovery from staff who only need to be informed. Roles such as incident commander, communications lead and external liaison are assigned to named people, with deputies, and permissions are set so that only those roles can post to external-facing announcements. Directory sync and single sign-on are checked so that a rota change updates access. The step is complete when a test incident channel shows the correct membership for each group and the deputies can take over the roles.
Set retention, legal hold and export
Compliance and legal define how long incident messages, files and membership changes are kept, and the platform team configures retention so that records of activities before and during a disruption are preserved as Article 11(8) requires. The team confirms which edition features provide retention rules, legal hold and export, and asks the vendor to confirm them in writing for the edition chosen. A sample export is produced and reviewed by an independent party to check that it is complete and readable. The step is done when a recorded export from a test channel can be opened and the retention settings match the policy.
Document the communication owner and the message set
The entity appoints at least one person to implement the communication strategy for ICT-related incidents and to act as the public and media contact, as Article 14(3) requires. The owner, a named deputy, and pre-approved message templates for staff, clients, counterparts and the public are stored in the crisis procedure, along with the rules for when disclosure of major incidents is considered. The templates are kept in the chat platform and in an offline copy. The step is complete when the procedure names the owner, the deputy and the approval chain, and an auditor can trace each template to the policy.
Test with tabletop exercises
The crisis management team runs a tabletop exercise that includes a cyber-attack scenario, because Article 11(6) requires entities other than microenterprises to include such scenarios in their tests. The scenario is set so that the primary ICT services and the identity provider are unavailable, and participants must open incident channels, follow the communication owner's procedure and draft a staff and client message through the chat. Facilitators record what worked, which accounts failed to log in, and where the decision path was unclear. The step is complete when a written report lists each finding with an owner and a due date set by the entity.
Test switchover and fallback
The platform team tests the switchover from the primary chat environment to any redundant capacity, and confirms that messages, membership and files are available after the switch. Where high availability is used, the team checks failover behavior against the vendor's documented cluster design, and confirms that the shared file storage and database replicas are reachable from each node. The team also checks that responders can still reach a fallback channel if chat itself fails. The step is complete when the switchover test results, including timings and any data gaps, are recorded and the fallback plan is updated.
Retest yearly and after substantive changes
The entity repeats the continuity and crisis communication tests at least once a year and after any substantive change to the chat platform, its identity provider, its hosting or the systems it supports, as Article 11(6) requires. Each upgrade, including monthly server releases or a move between long-term support versions, triggers a check of the dependency register, the retention settings and the roles. Results feed back into the business impact analysis, so the record of the channel stays accurate. The step is complete when each test cycle has a dated report, a list of corrective actions and an updated dependency register that the internal audit function has reviewed.
What auditors and supervisors ask to see as evidence
What evidence shows a DORA crisis communication plan exists and works?
The entity holds the crisis communication plan itself, approved under its ICT business continuity policy, and records showing it was tested. Article 14(1) and Article 11(6)(b) both point at this plan. The chat platform supports it by hosting a documented crisis channel, such as a dedicated Mattermost channel or a Rocket.Chat room, with its purpose, owners and escalation path written into the plan. Whether this evidence is adequate is decided by the entity's own auditors and its competent authority, not by the chat vendor or DeployOpen.
What test records prove crisis communication was exercised under Article 11(6)?
Test records show the date, scenario, participants, channels used and the result of each exercise. Article 11(6) requires testing at least yearly and after substantive changes, and it expects cyber-attack scenarios and switchovers to redundant capacity to be included for entities other than microenterprises. In a self-hosted chat deployment, the platform's audit and channel logs can confirm that messages were sent and received during the drill. Auditors will also look for evidence that the chat service stayed reachable when the primary environment was simulated as down, so the entity should test that switchover explicitly.
Which business impact analysis extract should link to the crisis channel?
The extract should show which critical or important functions depend on the chat service and the recovery priority assigned to them. Article 11(5) requires a business impact analysis of severe disruption using quantitative and qualitative criteria and scenario analysis. Chat is a dependency for incident coordination, so the analysis should state what happens if chat is unavailable and which fallback channel applies. Ask your team to confirm the analysis itself with its risk function, since the chat platform does not produce it.
What role assignments prove who owns crisis communication in chat?
Auditors expect a named person, or named roles with deputies, for implementing the communication strategy and fulfilling the public and media function under Article 14(3). They also expect a split between staff who respond and recover and staff who only need to be informed, as Article 14(2) requires. In chat, this maps to role-based membership in incident channels, with a separate read-only or announcement channel for informed staff. Keep the role register in the entity's HR or identity system and export the matching group membership from the directory integration.
What channel and membership configuration should an examiner review?
Examiners look at the list of crisis channels, who can create them, who is a member, and whether external parties are admitted. The platform produces this as channel settings, membership exports and team or group configuration. Document which channels are private, which are read-only, and whether federation or guest access is enabled for counterparts. Mattermost and Rocket.Chat both expose channel and user administration, but the entity must confirm the exact export formats in the edition it licenses.
Which retention settings show crisis messages are kept as required?
The evidence is the documented retention policy for crisis channels and the platform setting that applies it. Article 11(8) requires readily accessible records of activities before and during disruption events when plans are activated, and the retention period must match the entity's own record-keeping rules. Confirm with the chat vendor which retention and legal hold features are included in the edition you choose, because some are paid features. Test that deleted or expired messages follow the documented rule, and keep a dated record of the setting.
Which activity logs must be kept while a crisis plan is active?
Entities must keep readily accessible records of activities before and during disruption events when plans are activated, as Article 11(8) requires. For chat, this means server and audit logs covering logins, channel creation, membership changes, administrative actions and message activity during the incident window. Store these logs outside the affected environment so they remain available if the chat service fails. Ask your implementation partner to confirm which audit trails the chosen edition provides and how they are exported, and have your security team set retention for them.
What the chat platform alone does not satisfy
A chat platform delivers messages, but DORA expects an entity to show that its crisis communication, continuity and recovery arrangements work as a whole. The cards below cover the governance work, the dependencies and the lifecycle obligations that the channel cannot meet on its own.
Crisis communication plan authorship
Article 14(1) requires a crisis communication plan that enables responsible disclosure of major ICT-related incidents to clients, counterparts and, as appropriate, the public. The chat tool holds the channels, but the plan must name who speaks, to whom, in what order and with which approved wording. Check that the plan exists as a signed document and that the chat workspace reflects its audiences, such as a response group and a separate staff-informed group.
Responsible disclosure thresholds
The entity must decide which incidents or vulnerabilities trigger external disclosure, and who makes that call under time pressure. No messaging product can classify an incident for you. Document the thresholds, link them to the incident classification process, and rehearse the decision path so that staff do not improvise severity judgments in a shared channel.
Business impact analysis
Article 11(5) requires a business impact analysis of exposure to severe business disruptions, using quantitative and qualitative criteria and scenario analysis. The chat platform does not identify critical functions or estimate losses. The analysis determines which communication paths must survive an incident and how long they must do so, so it should be completed before the chat channel is designed.
Independent internal audit of response plans
Article 11(3) requires ICT response and recovery plans, for entities other than microenterprises, to be subject to independent internal audit reviews. A self-hosted platform produces logs, but reviewers need evidence that the plan was examined by someone independent of its owners. Confirm the audit scope, the reviewer's independence and the findings register before the first audit cycle.
Switchover and communication testing
Article 11(6) requires continuity and response plans to be tested at least yearly and after substantive changes, including switchovers to redundant capacity, and requires crisis communication plans to be tested. A chat channel that has never been exercised during a simulated outage of the primary infrastructure is unproven. Schedule tests that move staff to the fallback channel, record response times and feed results back into the plan.
Public and media function
Article 14(3) requires at least one person to implement the communication strategy for ICT-related incidents and to fulfil the public and media function. This is a named role with a deputy, a press process and authority to speak, not a feature. Confirm who holds the role, how they reach the response group when the primary channel is down, and where external statements are approved.
Shared dependencies with the failing estate
A chat service that relies on the same identity provider, DNS zone, email domain or cloud region as the systems that failed will be unavailable when it is needed most. Map each dependency of the chat platform, including directory sync, push delivery and certificates, and confirm that at least one path avoids every shared component. Document the out-of-band contact method for staff and for the communication lead.
Documented upgrade policy
Open-source chat platforms move on fixed release cycles, and an unsupported version may stop receiving security fixes and stop working with official clients. Mattermost publishes server releases monthly and sets support end dates per version, and Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. Write an upgrade policy that keeps the channel inside a supported line, and record each upgrade as a change that may require a continuity test.
How much does a DORA-ready crisis chat cost and how long does it take
What drives the cost of a self-hosted crisis chat for DORA?
The cost is driven by four things: the chat edition you license, the infrastructure you run it on, the identity integration you need, and the testing that proves the crisis channel works. Open-source server software carries no license fee under the MIT license that covers Mattermost compiled releases or the MIT license used for most Rocket.Chat code, but the paid tiers that add features such as SSO, high availability or air-gapped deployment are priced by quote. Hosting, storage, backup, monitoring and staff time recur every year. Ask any partner for a written scope that separates one-time build work from recurring operations, and for each licensed feature, the plan that includes it.
Which Mattermost or Rocket.Chat plan do we need for clustering or air-gap?
For Mattermost, high availability clustering is available only on the Enterprise and Enterprise Advanced plans, and air-gapped deployment is listed for Enterprise Advanced. For Rocket.Chat, multi-instance and microservice reference architectures require a paid plan, and air-gapped deployment is a paid-plan capability that is not available on the free Starter plan. Confirm the exact feature mapping against the current pricing pages and your required seat count before you commit, because plans are sold as annual subscriptions or priced by quote. A single-instance design may run without clustering, but that choice must be justified against your crisis recovery requirements.
Can our own IT team run a DORA-grade crisis chat internally?
Many organizations can run a chat platform internally, but a crisis channel adds requirements that often need a second pair of hands. The platform needs upgrades on a fixed cadence, since Mattermost publishes a new server version each month and Rocket.Chat versions lose security fixes after end of life. Mattermost high availability needs shared file storage on S3, an S3-compatible service or NAS, and Rocket.Chat 8.x needs a MongoDB replica set. Your team must also run failover tests, document them for the Article 11 testing requirement, and keep the communication plan current. Assess whether your staff can cover these tasks without the same people who respond to incidents.
What do IT, security and compliance teams need to provide?
Each function contributes a different input. IT provides the hosting platform, network paths, DNS, storage, database and backup design. Security defines identity integration, access roles, encryption, logging and the rules for which staff are involved in response and recovery versus those who only need to be informed. Compliance maps the crisis communication plan to the DORA articles on crisis communication and business continuity, and sets evidence expectations for tests and records of activity during disruption. Business continuity owners decide who speaks for the entity to clients, counterparts and, where relevant, the public. Agree these responsibilities in writing before the build starts.
How long does a fixed-scope crisis chat project take?
No duration is fixed in the supplied facts, so the timeline must come from your written scope. A reliable scope sets out the edition, number of users, identity integration, hosting model, high availability design, migration source, and the number of failover and communication tests. The schedule depends on how quickly your infrastructure, identity provider and storage are available, and on how many test cycles your business continuity owners need. Ask any partner to name the milestones, the acceptance criteria for each one, and what must be ready before the crisis channel is considered in service. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Which testing costs should we budget for a DORA crisis channel?
Testing is a recurring cost, not a one-off event. Article 11 requires continuity and response plans to be tested at least yearly and after substantive changes to systems supporting critical or important functions. For the crisis channel, that means failover tests of the chat servers, database and storage, plus exercises that confirm staff can reach each other when the primary environment is degraded. Each test requires planning time, staff participation and a written record of results. Ask a partner to price the test cycles separately from the build, and to state whether the test scenarios include cyber-attack and switchover cases.
What does identity integration add to the cost?
Identity integration is one of the largest drivers because a crisis channel must authenticate staff reliably when other systems are impaired. Mattermost lists SSO (SAML, OIDC, OAuth) and AD/LDAP user sync from the Professional plan, while Rocket.Chat includes LDAP, Active Directory and single sign-on on its Starter plan and lists user group mapping on paid plans. Costs rise when the directory is complex, when multi-factor authentication policies differ across groups, or when external parties need access. Define which accounts must work during an identity provider outage, because a crisis channel that depends on the same directory as everything else may fail with it.
Does a DORA crisis chat need a paid edition for retention and audit?
Retention and audit features may need a paid edition, so confirm them before you choose the plan. Rocket.Chat lists tamper-evident audit trails for messages, files and sessions on paid plans, and its free Starter plan includes retention. Mattermost publishes its feature split on the pricing page, which should be checked against your retention and export needs. DORA does not prescribe a chat product, but Article 11 expects readily accessible records of activities before and during disruption events. Verify with each vendor that the edition you buy provides the export and retention behavior your compliance team requires.
Which DORA scope and sibling obligations change the design
Whether DORA binds your chat architecture at all depends first on entity type. Article 2(1) applies DORA to 20 types of financial entity, from credit institutions and payment institutions to insurers and crypto-asset service providers, and point (u) also reaches ICT third-party service providers. A bank, an insurer and a technology vendor selling into the sector will read Article 14 and Article 11 differently, and a crisis channel run by a provider serving several financial entities may be scoped as an ICT third-party arrangement rather than an internal tool. Before you specify hosting, confirm with your legal or compliance team which point of Article 2(1) you fall under and whether any of your ICT providers are in scope under point (u). That answer decides who must be on the channel, who owns its records, and which contract terms your chat vendor or implementation partner must accept.
Article 1(2) adds a second layer. For financial entities that are also essential or important entities under NIS2, DORA operates as the sector-specific Union act referred to in Article 4 of the NIS2 Directive, so the same crisis channel may need to satisfy both regimes. Do not assume that one design covers both without checking. Our sibling page on self-hosted team chat for NIS2 secured communications covers the NIS2 side in detail. Separately, Article 58(1) requires the Commission to review DORA by 17 January 2028, including the voluntary nature of significant cyber threat notification. Treat that review as a planning trigger: build the channel so that notification and disclosure workflows can change without rebuilding the platform. Supervision remains with the national competent authority for each entity type under Article 46, with the ECB responsible for significant credit institutions, so the authority that will ask for your evidence may differ from the one you expect.
If you operate a regulated trading or recordkeeping business, the crisis channel will also carry business communications subject to recordkeeping rules. The self-hosted team chat for financial services page addresses retention and legal hold under rules such as SEC Rule 17a-4. The point for this topic is that incident messages may become records in their own right, and the retention setting that suits day-to-day chat may not suit incident traffic. Ask your compliance lead which regime applies to incident channels specifically and whether they must be exported, held and reviewed separately from general channels, before you decide on retention periods and which edition of the platform you need.
Which phases a DeployOpen engagement follows
The sequence turns the DORA communication requirements into a configured, tested and documented chat channel that stays available when the primary environment is degraded. Each phase ends with an artifact the entity's own compliance and audit teams can review.
Scope against the written requirement map
DeployOpen starts by mapping the entity's crisis communication requirements, drawn from its ICT business continuity policy, its Article 14 crisis communication plan and its Article 11 response and recovery plans, to specific chat capabilities. The map records who must be reached in an incident, which staff are responders and which only need to be informed, and which external counterparts and authorities are included. The scope, deliverables and timelines are agreed in writing before work starts. The output is a signed requirement map that both sides use as the acceptance baseline.
Decide architecture and hosting
Next, the team selects the platform (Mattermost, Rocket.Chat or Matrix) and the hosting model based on the entity's infrastructure, its independence requirements and the expected user count. The design covers whether the channel runs outside the production network or in a separate failure domain, how the database and file storage are replicated, and which edition provides high availability. Editions that include clustering, SSO or air-gapped operation are confirmed against current vendor documentation, not assumed. The output is an architecture decision record with the chosen edition and the failure modes it addresses.
Configure identity, roles and channels
DeployOpen configures single sign-on and directory synchronization so that incident responders and informed staff are provisioned from the entity's existing identity source. Crisis channels, roles and membership rules are created to match the differentiation between response and recovery staff and staff who only receive updates. Break-glass accounts are created outside the normal identity path and stored under the entity's own control. The output is a configuration baseline, with a list of accounts, groups and channels that the entity's identity owners have reviewed.
Test with crisis scenarios
The team runs tabletop-driven technical tests against the requirement map, including scenarios that disable the primary identity provider, the main database or the production network segment. Each test records whether responders can reach each other, whether notifications reach external counterparts through the approved path and how quickly the team can switch to the fallback channel. Findings are logged with an owner and a retest date. Article 11(6) expects these plans to be tested at least yearly and after substantive changes, so the entity should confirm its own test calendar. The output is a test report with pass, fail and remediation status for each scenario.
Package evidence for auditors
DeployOpen assembles the evidence the entity's internal audit and external assessors will ask for: the requirement map, architecture decisions, configuration baseline, access reviews, test reports and the records of activity kept during activation. The package is organized by DORA article so reviewers can trace each requirement to a control and a test result. DeployOpen prepares this material but does not issue audit opinions or attestations; the entity's auditors and supervisors make those determinations. The output is an evidence binder that the entity owns and can hand to its assessors.
Run go-live and handover
Before go-live, the team completes a cutover rehearsal, confirms that the crisis contact list and emergency runbook link to the new channel and trains the named communication owner and backup. The handover covers administration, backup and restore procedures, and the upgrade calendar. Since vendor release cadence and support windows change, the entity must confirm which version lines are supported and how upgrades will be tested before they reach production. The output is a signed handover record and a completed runbook.
Support, upgrade and retest under retainer
After go-live, ongoing support, upgrades and periodic retesting can be covered by a retainer agreed in writing. DeployOpen applies vendor patches and version upgrades in a staging environment, reruns the affected crisis scenarios and records the results in the evidence package. Substantive system changes trigger a retest, as the regulation requires. The output is a current evidence package and a dated log of upgrades and test results.
How DeployOpen scopes, delivers and supports the crisis chat
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a DORA crisis channel, that means agreeing in writing what the channel must do during an ICT incident, building it to keep working when primary systems are degraded, and handing your team the evidence and runbooks to test it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope maps which staff are response and recovery participants and which only need to be informed, as Article 14(2) requires.
- We confirm which edition, plan or licence features your crisis messaging depends on before any build begins.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, separate from the production systems it must outlive.
- We configure SSO, directory sync, dedicated crisis channels, notification paths and access for the named crisis communication roles.
- We test the crisis communication plan against cyber-attack and failover scenarios, as Article 11(6) expects, and record the results.
How we hand over
- You receive written documentation of architecture, configuration, access roles and the crisis communication runbook.
- Handover covers the procedures for activating the channel, logging activity during a disruption and communicating with clients and the public.
- Your named staff are trained to run the channel, including the person tasked with the public and media function under Article 14(3).
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the channel is tested again after substantive changes.
- Upgrades follow the vendor's release and support windows, which you should confirm with the platform vendor before scoping.
- Retesting of the crisis plan and review of audit evidence can be scheduled as part of the retainer, agreed in writing.
