Open source digital workplace suite for NIS2

Forward authentication events from the identity provider, file access and sharing events from the file platform, admin and login events from the mail server, and channel, login and admin events from the chat platform into one central log store. Identity logs matter most because most suspicious activity starts with a login, such as a new device, impossible travel or repeated failures followed by success. Add the reverse proxy and ingress logs for the Kubernetes layer, since they show the source address and request path for every browser session. Keep the list in writing and confirm with each vendor which audit events each release actually emits, because event names and retention settings differ between components. Test that a sample event from each source arrives and can be searched before you rely on the pipeline.

Your organization decides, through the incident response roles it defines in advance, and the decision should not wait for the security team to finish its investigation. NIS2 Article 23 requires essential and important entities to report significant incidents to their national computer security incident response team or competent authority, using an early warning, an incident notification and a final report. The directive sets these reporting duties, but the exact deadlines and the recipients are set by national transposition law, so you must confirm the timelines and the authority in your country before writing the playbook. Name a decision owner, a deputy, and the criteria for significance taken from Implementing Regulation (EU) 2024/2690 if you fall within its scope. Record every decision and its reasons, because the record is itself evidence during supervision.

Revoke at the identity provider first, because every application in the suite should trust its tokens and sessions. Disable or lock the account, then end active sessions and refresh tokens, so that a stolen token stops working at the next validation. Applications that cache sessions or issue long-lived app passwords, such as mail clients or sync clients, need a separate revocation step that you should document and test. Confirm for each component whether it honors upstream logout and token revocation, since some keep local sessions until they expire. Keep a runbook with the exact admin steps per application and check that the administrator account used for this action is itself protected by strong authentication and logged.

A typical containment sequence has four parts: disable the account, revoke its sessions and tokens, remove or restrict its sharing links and external shares, and block the source addresses or devices involved. Next, review recent file downloads, shares to external recipients, mail forwarding rules and new chat integrations created by the account, because attackers often set these up to keep access. Restore only after the account is verified and credentials are reset. Keep containment reversible and logged, so that the response does not destroy the evidence you need later. Treat service accounts and shared mailboxes separately, since they often lack a single owner and may have broader permissions.

Preserve evidence before you clean up, by exporting relevant logs, database snapshots and object storage versions to write-protected storage with a recorded hash. Capture the state of the account, its sharing links, mail rules and group memberships as they were at the start of the incident. Keep a chain-of-custody record that names who exported what and when. Do not reimage affected nodes until the platform team has taken snapshots, because container restarts can erase in-memory and ephemeral data. Confirm with your legal and compliance teams how long evidence must be held, since retention needs differ by sector and jurisdiction.

Run tabletop exercises that walk the decision owner through a realistic scenario on paper, then run a technical drill that disables a test account and checks each step in the runbook. Measure how long it takes to find the account, revoke sessions in every application and confirm that logs were captured. Record gaps as tracked actions with owners and dates. Repeat the drill after each major upgrade, because event names, admin paths and session behavior can change between releases. Keep the exercise records, since they support the evidence that your risk management measures operate in practice.

Your own team can run the process if it already operates an incident response function and has administrative access to each component, but the suite adds specialized steps that many teams have not practiced. The skills needed include Kubernetes log access, application admin consoles for each tool and the identity provider configuration. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and can prepare the log forwarding, runbooks and drill material as part of a fixed-scope engagement that is agreed in writing before work starts. Ongoing support and continuous testing are available as retainers. Ask any partner to show how it will hand the runbooks and access to your staff, so that the process still works after the engagement ends.

The main costs are the log storage and the people who build and run the detection rules, the drills, and the administrative time needed for containment. Log storage recurs with volume and retention, so the amount of data from identity, file, mail and chat sources drives the cost more than the number of users. The implementation work is one-time, covering log forwarding, runbooks and the first exercise, and is priced from the written scope rather than a list. Ask any provider for a quote that separates implementation from recurring operations, names the log sources in scope, and states the retention period and the storage location. No single figure applies across organizations, so confirm your own volume and retention needs before comparing offers.

No. NIS2 creates no certificate of compliance, so no product or vendor can make a suite NIS2 compliant on its own. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your entity is responsible for its risk-management measures under Article 21, and the workplace suite is one part of that evidence. The implementation work can prepare controls, configuration records and logs that your assessors will review, but it does not replace an assessment by your authority or an independent auditor. Confirm with your national transposition law which obligations apply to your entity and whether it is classified as essential or important.

No duration can be stated responsibly before the scope is known, so ask for a written scope and timeline before work starts. Most engagements are fixed-scope, and the scope document should list the components in use, the number of users, the identity sources, the external services and the evidence to be delivered. The timeline depends on how many components are deployed, whether data is migrated from existing systems, how much of your Kubernetes platform already exists and how quickly your own teams can review and approve changes. Ask the partner to show each milestone, the dependencies on your team and the acceptance criteria for each deliverable.

Expect to supply decisions and access as well as people's time. Your team will typically need to provide the Kubernetes platform, the external services the suite depends on, identity and directory administrators, and a business owner who can accept scope changes. For a production openDesk deployment, the requirements documentation expects external production-grade services such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Your security team should also define the access control model, the logging destinations and the incident contacts before configuration begins. Ask the partner to list these inputs in the written scope, with an owner for each.

Yes, many organizations with mature platform teams do, but the work is larger than installing software. Self-hosting means your team owns the supply chain checks for charts and images, the identity integration, backups, upgrades, hardening, monitoring and documentation for every component. The openDesk deployment is Helmfile and Helm based, and each bundled component keeps its own license, so license obligations also need an owner. Assess your team against each NIS2 risk-management area and the operating roles needed over time. A partner can take on part or all of this under a written scope, while you keep decision rights and the evidence trail.

The cost has four main parts: the infrastructure your organization pays for, the implementation scope paid to the partner, the support model, and the internal staff time. Infrastructure and external services recur every year, while implementation work is usually one-time, although configuration changes and upgrades recur. The largest cost drivers are the number of components in scope, the number of users, the identity integration complexity, data migration volume, the depth of hardening and evidence you require, and whether you buy vendor support. For the Enterprise route, Nextcloud's pricing page lists Standard, Premium and Ultimate tiers with a 100-user minimum, and openDesk Enterprise Edition is sold as SaaS or for on-premises installation. Ask every quote to separate one-time and recurring items, name the licenses, and state what the partner does not cover.

ZenDiS recommends openDesk Enterprise Edition for production, but whether your organization needs it depends on your support model, risk appetite and procurement rules. Enterprise Edition uses the same open-source core licenses and adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed 2nd and 3rd level support and patches. Enterprise-only features include Nextcloud Enterprise security patches and the Guard app, Collabora branding and automatic load scaling, and GroupSync with the Admin Console. Without Enterprise support, you rely on the community release cycle and your own or your partner's capacity to test and apply patches. Confirm with the vendor which support tier applies, and ask your partner how it would handle a security patch that falls outside your SLA.

Every upgrade changes the configuration, versions and sometimes the controls your evidence describes, so each upgrade must update the record. openDesk plans minor releases monthly and only supports the latest minor version, and in-place upgrades between majors are not guaranteed. Nextcloud does not allow skipping major releases, so administrators must upgrade one major version at a time, back up before every upgrade and disable third-party apps until they are confirmed compatible. Ask the partner to keep a dated change log, a versioned bill of materials with image digests, test results for each upgrade and a rollback record. Your evidence set should show the version in service on each date an assessor examines.