Intranet software requirements checklist

Intranet software requirements checklist: how to use it before you compare platforms

Before you compare HumHub, XWiki or Nextcloud as an intranet, agree on the requirements that any candidate must meet. The checklist on this page is organized into five groups: functional, security, integration, operational and compliance needs. Each row is written as a yes or no test, so during evaluation you mark every candidate pass or fail against the same rows instead of against the demo that looked best. Rows that fail for a hard constraint, such as an edition that lacks the directory or SSO method your security team requires, eliminate the candidate. Rows that fail for a soft preference go into a gap list with an owner and a cost to close.

Write the requirements first and let the platform choice follow them. Teams often start from a familiar product and then trim their needs to fit it, which hides gaps until rollout. Begin with the audiences and spaces you must support, the directory and single sign-on method your identity team will operate, the mobile access your frontline staff actually need, and who moderates news and approves content. Then map each requirement to the edition and feature that supplies it. For example, confirm whether the LDAP, OpenID Connect or SAML capability you need is in the community build or only in a paid tier, and ask the vendor to show it working against your directory. The Nextcloud LDAP documentation is a useful reference for what to verify.

Record the answers in one document that the business owner, security, identity, compliance and the implementation partner all sign. Include the hosting location and support model as explicit rows, because they change which editions and upgrade paths are viable. Keep the checklist short enough to use in a workshop, and review it again before the final vote. Confirm every version, support window and licensing term with the vendor at the time of purchase, since these change between releases and the research behind this page reflects a single point in time.

Functional requirements to settle: audiences, spaces, news and moderation

This table lists the functional requirements to settle before choosing an intranet platform, with why each matters and how to verify it. Use the verification column as a pilot script: run each test with a real group of users, not a feature list copied from a vendor page. Edition-specific features must be confirmed with the vendor in writing.

Requirement	Why it matters	How to verify with a pilot group
Audiences and spaces per department or site	Spaces define who sees which news, files and discussions, and a flat structure leads to noise or leaked content.	Create three test spaces (one department, one site, one cross-company) and confirm a pilot user outside each space cannot see its content or notifications.
Targeted news and notices	Communications teams need to reach a shift, a plant or a role without sending everything to everyone.	Publish a targeted notice to one site group and check that only members receive it, on desktop and mobile, with the notification text intact.
Mandatory read notices and acknowledgement	Policy and safety messages often need evidence that staff saw them, which email blasts do not provide.	Ask the vendor whether read tracking exists in your edition, then test it with five pilot users and export the acknowledgement list.
Comments and reactions	Open comments drive engagement but can spread personal or sensitive information.	Post a comment as a pilot user, then check whether authors can edit or delete it and whether the author and time are recorded.
Moderation roles and audit trail	Someone must remove harmful content quickly, and reviewers need a record of what was removed and by whom.	Assign a test moderator, remove a flagged post, and confirm the action is logged and the original author is notified according to your policy.
Profiles and org structure	Directory-driven profiles, reporting lines and job titles make search and targeting usable.	Sync a sample of accounts from your directory, then confirm name, title, department and manager fields appear correctly and update after a change.
Mobile access, including frontline staff without corporate email	Plant, retail and field staff may use shared devices or personal phones and may not have a mailbox or directory account.	Give five users with a non-corporate identity a mobile login through your chosen method, then confirm they can read a site space and nothing outside it.
Shared kiosks or devices	Shared devices require logout behavior and session limits so one shift does not expose another shift's content.	Log in on a shared browser, log out, and confirm the next user cannot open the previous session or cached pages.

Directory, SSO and login requirements by identity model

When every employee has an account in Active Directory, the main question is whether the intranet can read that directory and authenticate users against it. Nextcloud's LDAP app lets LDAP and Active Directory users appear in Nextcloud and log in with their directory credentials, so this is a documented, native path for Nextcloud deployments. For XWiki, the XWiki Pro offering lists Active Directory SSO applications, which means the directory integration sits in a paid edition rather than the free Standard edition. Confirm which edition covers your exact directory and authentication method before you assume it is included.

Bind account and search scope: Confirm the service account, its read permissions and which organizational units hold employees, contractors and disabled accounts.
Group mapping: Decide whether directory groups drive space membership, admin roles and access to sensitive areas, and verify the platform can read nested groups.
Deprovisioning: Test that a disabled directory account loses access and that existing sessions and API tokens are revoked.
Secure transport: Verify LDAP connections use encrypted transport and that the service account password is stored and rotated under your standard process.
Edition check: Ask the vendor or partner which edition and version support Active Directory login for your domain setup.

Confirm these items in a test tenant with a representative group of accounts before the directory design is signed off.

Security requirements that every intranet candidate must meet

Regulated readers will ask the same questions of every intranet candidate: how content moves, who can see it, what gets logged, and how it is restored. The cards below set the baseline each platform must clear before feature comparison begins. Confirm every control with the vendor and in a test environment, because the depth of these features varies by product and edition.

Encryption in transit

Every session between a browser, mobile app, sync client and the server should use TLS, and any LDAP or directory connection should be encrypted as well. HIPAA's Security Rule (45 CFR 164.312(e)(1)) expects technical measures that guard against unauthorized access to electronic health information sent over a network, and regulated readers will apply the same question to employee data. Ask which protocol versions and cipher settings the platform enforces by default, and whether plain HTTP is blocked or redirected.

Access control by space and role

Intranet spaces often mix public company news with restricted HR, legal or plant-level content. Each space needs its own membership, read and write roles, and the ability to hide a space from search results. Test whether a user outside a restricted group can find it through full-text search, attachments or notifications, not only by browsing. Confirm whether the platform can separate administrative roles from moderation roles.

Audit logging of views and changes

HIPAA's audit control requirement (45 CFR 164.312(b)) expects systems holding sensitive data to record and examine activity, and broker-dealer rules under 17 CFR 240.17a-4 set multi-year retention for certain business communications. Intranet logs must show who viewed, edited, moved or deleted content, and when. Many platforms log edits but not page views, so ask each vendor exactly what is recorded, how long it is retained, and whether logs can be exported to a SIEM. Confirm retention settings with the vendor before relying on them.

Admin and third-party app governance

Plugins, apps and custom themes extend the attack surface and are often maintained by a single developer. Require a written list of approved extensions, a change process for installing or updating them, and the ability to disable an app without a full redeployment. Ask whether administrator actions are logged separately and whether admin accounts can require multi-factor authentication. Note which extensions are supported by the vendor and which are community code.

Backup and restore testing

A backup that has never been restored is an assumption, not a control. Intranet backups must cover the database, attachments, configuration and search indexes, and they must be restorable to a separate environment. Schedule a restore test after every major upgrade and record the time to recover. Some stacks bundle backup tooling, but the retention, encryption and offsite copy decisions remain the client's responsibility.

Patch cadence and upgrade path

Each platform publishes a release and support lifecycle, and older branches stop receiving security fixes. Confirm which versions are supported, how often security releases ship, and whether major versions must be applied in sequence. Nextcloud, for example, does not allow skipping major releases during upgrades, so a patch plan must budget for each step. Ask for the support window in writing and the process for emergency fixes outside the normal schedule.

Document and wiki integration: where the intranet ends and the file store begins

The intranet should own announcements, policy pages and how-to content, while the file store should own working documents and their version history. Settle this boundary before choosing a platform, because it determines which system users search first, which one holds the authoritative copy of a policy, and which one enforces access. If both platforms hold a copy of the same handbook, the copies will drift within months. Write down, for each content type in your inventory, the system of record, the system that links to it, and the owner who approves changes. A short table of content types is enough for this decision, and it becomes the basis for the permission model you test later.

Permission sync is the control most likely to fail quietly. A file shared to a project folder in the file store can be visible to people who should not see it if the intranet space that links to it grants broader access, and the reverse is also true. Confirm with each candidate whether group membership and directory attributes flow from the same identity source to both systems, whether removing a leaver from the directory removes access in both places on the same day, and whether an intranet link to a restricted file reveals the file name to unauthorized readers. For a single source of truth on policies, pick one canonical location, make the intranet link to it rather than copy it, and assign a page owner who is accountable for review dates. XWiki Pro lists Google Apps, Office365 and OnlyOffice connectors, and Nextcloud's ecosystem includes ONLYOFFICE Docs and Collabora Online as document editors. Before relying on either, confirm with the vendor that the connector version, edition and license terms fit your chosen editor, since AGPL-3.0 and MPL 2.0 obligations differ for hosted and modified deployments and should be reviewed with counsel.

Integration requirements: directory, email, chat, helpdesk and HR systems

An intranet rarely works alone. Profiles, notifications, chat links, documents and employee requests all depend on systems that already run in the organization. Settle these integrations before choosing a platform, because each one changes what the edition, the hosting and the project plan must cover.

Directory and HR profile sync

Decide which system is the source of truth for names, departments, managers, locations and leavers, and whether the intranet reads it on a schedule or on each login. Confirm whether the chosen edition supports LDAP or Active Directory user sync and deprovisioning of departed staff, and whether group membership can drive space access. Plan who approves changes to the mapping rules, since a wrong department field can expose spaces to the wrong audience.

Single sign-on and login policy

List the identity provider, the protocols it speaks (SAML, OpenID Connect or directory bind) and where multi-factor authentication is enforced. Confirm that each candidate platform supports the protocol in the edition you plan to buy, and whether local accounts remain for contractors or break-glass use. Ask how session lifetimes and logout propagate, because a shared workstation with an open intranet session is a common finding in access reviews.

Email and calendar notifications

Map which events send email: news, mandatory read notices, mentions and file shares. Confirm the sending domain, SPF, DKIM and DMARC records, and whether notifications carry content or only a link to log in. Notifications that quote policy text or patient or client details move sensitive data into mail archives, so agree the content rule with the email owner before go-live.

Team chat and collaboration links

If staff already use a chat platform, decide whether the intranet only links to channels or also posts into them. Confirm whether the edition offers an existing chat connector or whether a webhook or custom integration is needed. Each link pattern creates a route from the intranet into chat, so check that channel access follows the same group model as intranet spaces.

Document and wiki systems

List the file shares, document management systems and wikis that the intranet will reference or embed. Decide whether pages link to the source document or copy it, and who owns version control when both exist. Confirm whether file permissions are respected when a link is opened, because an embed that bypasses the source system can show content to people who should not see it.

Helpdesk and ITSM for employee requests

Identify which requests start on the intranet (access, equipment, HR forms) and which system records them, such as a service desk or helpdesk. Agree the ticket fields, the status updates sent back to the employee, and who owns the queue. Confirm whether a native connector exists in the chosen edition or whether an API integration must be built and maintained by a named team.

How to verify search, hosting and performance before committing

This sequence tests whether the shortlisted intranet can find the content your staff need, respect existing permissions, hold up under pilot use, and run on the hosting and software versions you can actually support. It ends with a documented go or no-go decision.

Define realistic test queries
Before opening any product, the intranet owner and two or three frequent content authors write down three to five queries staff really type, such as a policy name, a holiday schedule, a project wiki page or a expense form. Cover news, documents and wiki pages so each content type is tested. Record the expected result for each query, including which page should rank first. Illustrative example: a query for "travel policy" should return the current approved policy, not an archived draft. The step is complete when the list is signed off and stored with the evaluation criteria.
Build a test tenant with realistic content
The platform team loads a non-production instance with a representative sample of news posts, files, and wiki pages, including duplicates, old versions and attachments with mixed file types. Confirm with the vendor or the project documentation which search features ship in the base edition and which need an add-on or enterprise module, because search depth often depends on that choice. The step is complete when the sample set is indexed and the team can reproduce each test query.
Test search over permitted content only
Create at least three test accounts with different group memberships, one of which should have no access to a restricted space. Run the same queries as each account and confirm that results, snippets and file names appear only where that account has permission. Check that deleted or unpublished items do not show up in results. Any leak of restricted titles or text is a blocking finding. The step is complete when the permission matrix shows zero unauthorized results across all test queries.
Run a load test with pilot users
Invite a pilot group that reflects your largest department and a mobile-heavy group, then have them perform normal tasks for an agreed period: reading news, uploading files, editing wiki pages and searching. Measure page response times and search latency at peak pilot activity, and note any errors in the server logs. Ask the vendor or implementation partner for the load profile they used in their own testing, since published benchmarks rarely match your user mix. The step is complete when response times and error rates are written down against thresholds the business agreed in advance.
Confirm hosting target against requirements
Confirm where the system must run: on-premises, a private cloud, or EU-hosted infrastructure, and whether any data may leave that location for search indexing, push notifications or updates. Check that the chosen environment meets the platform's stated hardware and network requirements for your user count. Record any dependency on external services, because those can conflict with data residency rules. The step is complete when the hosting decision and its data flows are approved by security and legal owners.
Check database and runtime versions
Compare the database, PHP or runtime, and web server versions in your planned stack against the vendor's current system requirements page. As an illustrative example, the Nextcloud 35 system requirements list MariaDB 11.8 or PostgreSQL 18 as recommended, support a range of older database versions, and specify PHP 8.5 with 8.3 and 8.4 also supported, plus Apache 2.4 or nginx with php-fpm. Note which versions are supported rather than merely working, and check the release schedule for the end-of-life dates of the version you select. Ask your partner to confirm the same matrix for each candidate platform. The step is complete when a version table with a support status for every component is filed with the architecture document.
Record the go or no-go decision
Summarize the results from the query tests, permission checks, load test, hosting review and version matrix in one document. Mark each criterion as passed, failed or conditional, and list the owner for every open item. Include the upgrade path the vendor documents, such as whether major versions can be skipped, since that affects long-term maintenance. The step is complete when the sponsor signs the decision and the agreed fixes are scheduled in the implementation plan.

Operational requirements: upgrades, backups, support and ownership

This table compares the operational requirements an intranet platform must meet after launch, with a verification step for each. Use it to test candidate platforms against your own runbooks, not against vendor summaries. The main takeaway is that upgrade cadence, restore testing and named ownership matter as much as features, because an intranet that cannot be patched or restored becomes a liability.

Requirement	Why it matters	How to verify
Upgrade cadence and support lifecycle	Nextcloud ships a new major version every four months and supports each for one year, so the platform must be kept inside a supported line.	Map the current release against the published maintenance schedule and confirm the end-of-life date for each version you plan to run.
Major version path	Nextcloud does not allow skipping major releases, so a platform that falls behind must be upgraded one major version at a time.	Write the upgrade path from your current version to the latest supported one and time each step in staging.
Stable versus LTS line	XWiki publishes a stable line and LTS lines, and the choice sets how often you must upgrade and how long security fixes are guaranteed.	Confirm which line you will run, its end-of-support date, and how the vendor announces the next line.
Staging environment	Upgrades and app changes can break behavior, so production should never be the first place a new version runs.	Keep a staging copy with production-like data volumes and confirm that a test upgrade passes login, search, sharing and mobile access.
Third-party app compatibility	Nextcloud advises disabling third-party apps until they are confirmed compatible, and extensions often lag core releases.	Keep an inventory of every app and connector with its version, and retest each one in staging before each upgrade.
Backup and restore testing	A backup that has never been restored is an assumption, and intranet content often includes attachments, database records and user data.	Run a scheduled restore of the database and file store into an isolated environment and record the time taken and any data gaps.
Support hours and severity response	Security fixes and outages arrive at unpredictable times, and vendor support tiers differ in hours and response targets.	Obtain the written support matrix, confirm hours, severity definitions and response commitments, and match them to your on-call model.
Documentation and admin training	Upgrades and incidents depend on runbooks that a second administrator can follow without the original builder.	Ask for a runbook for install, upgrade, backup, restore and user lifecycle, then have a second administrator execute it in staging.
Named internal ownership	Intranet content, moderation, directory links and platform patching need an accountable owner in IT and in communications.	Record named owners for platform operations, content governance and identity integration, and confirm each has time allocated in their role.

Questions buyers ask before choosing an intranet platform and partner

What does intranet requirements work cost, and what drives it up?

The requirements work is a fixed-scope piece of consulting whose price follows from the agreed scope, so no single figure applies across organizations. The main cost drivers are the number of audiences and spaces, the number of identity sources and directories to connect, how many legacy portals and document stores must be inventoried, and whether the proof of concept runs against real content or sample data. Ask for a quote that lists each deliverable separately: requirements document, architecture, proof of concept, and any licensing you must buy. On the licensing side, the figures are vendor-specific. For example, XWiki lists Pro and support subscriptions by user count in four tiers: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users), according to XWiki pricing. Nextcloud Enterprise list prices start at 71.29 euros per user per year for Standard with 100 or more users, per the Nextcloud pricing page.

How long do intranet requirements and a proof of concept take?

The duration depends on how many audiences, directories and content sources are in scope, and on how quickly your stakeholders can make decisions. A small single-company intranet with one directory and clear owners moves faster than a multi-entity rollout with several legacy portals. Confirm the timeline in the written scope with your partner before work starts, and ask which milestones require your sign-off. A useful proof of concept tests the hardest requirements first: directory login, mobile access, moderation of a news post and an import of a representative sample of content. If a partner cannot tie the timeline to named deliverables, treat the estimate as unverified.

What does the requirements work need from our IT and HR teams?

IT needs to provide directory access, a view of the current identity sources, network and firewall details for the target hosting, and a decision on who administers the platform after go-live. HR needs to confirm the organizational structure, leaver and joiner processes, and which groups should map to intranet spaces. Communications or business owners must name the content owners for each space and approve the moderation rules. Expect the requirements to surface gaps, such as users without a directory account or spaces with unclear ownership, and agree in advance who resolves them. Ask your partner for a list of inputs and named client contacts before the first workshop.

Can an internal team define intranet requirements without a partner?

Yes, an internal team can write the requirements if it has access to the business owners, a working knowledge of directory services and a clear mandate to decide. The gaps usually appear in areas that need hands-on testing: how the chosen platform handles SSO, which edition includes the connectors you need, how mobile apps behave with your policies, and how a migration will treat permissions and history. A partner adds value by testing those points in a proof of concept and by documenting the result. Many organizations split the work: they own the requirements and governance, and bring in an implementation partner for technical validation and rollout. Decide early which parts you will not be able to verify internally.

Which intranet edition do we need for directory integration and SSO?

The answer depends on the platform and the protocol. Nextcloud's LDAP app lets LDAP and Active Directory users appear in Nextcloud and sign in with their directory credentials, and Nextcloud also documents OpenID Connect and SAML user authentication backends, as described in the Nextcloud LDAP user authentication docs. For XWiki, the Pro edition lists Active Directory and Azure Active Directory SSO applications, while the free XWiki Standard edition is the base product. Confirm for each candidate whether LDAP, SAML and OIDC are available in the edition you plan to run, whether they require paid extensions, and whether the support plan covers them. Test the exact directory setup in a proof of concept before you buy.

How do we meet SEC 17a-4 three-year retention for intranet communications?

If your firm is a broker-dealer, SEC Rule 17a-4(b)(4) requires you to preserve originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. An intranet is only in scope if it carries business communications that the rule covers, so classify the content types with your compliance team before deciding. Retention must be enforced by the platform or by an archive you control, and you must be able to show that deletion and edits follow your policy. Ask your partner how the chosen platform handles retention policies, versioning, legal holds and audit logs, and whether an archive integration is needed. DeployOpen prepares systems and evidence for compliance assessments, but auditors and regulators make the final determination.

What should we ask an implementation partner before signing?

Ask for the written scope, deliverables and milestones, with the acceptance criteria for each. Ask who will do the work, what experience they have with your chosen platform and which directory and identity setups they have implemented in your environment type. Confirm how they handle hosting inside your own infrastructure, backup and restore testing, and the upgrade path for major releases. For Nextcloud, ask how they will move through each major version, since upgrades cannot skip major releases and must be preceded by a backup. Ask what happens after go-live: support hours, response targets, and whether an ongoing retainer covers patches and upgrades. Finally, ask what they will not do, so the boundary of the engagement is clear before signature.

Questions that separate HumHub, XWiki and Nextcloud in the evaluation

Start with the login protocol, because it often decides which edition you must buy. Ask each vendor which protocol you need (LDAP, SAML or OpenID Connect) is included in the edition you would actually purchase. Nextcloud documents an LDAP app that lets Active Directory users log in with directory credentials, and it also documents OpenID Connect and SAML authentication backends. Confirm in writing which of these ship in the community release and which require Nextcloud Enterprise. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, and its Starter tier is cloud only with up to 25 users. For HumHub, confirm which edition covers LDAP and SAML and whether the license is one-time or recurring. Ask for a test login against your own directory before you commit.

Next, test how each platform handles spaces and permissions at scale, and how upgrades behave. Build a sample that mirrors your actual structure, including nested groups, read-only announcement spaces and restricted HR or legal areas, then check how permissions are inherited and how changes are logged. For frontline users, confirm that the mobile app supports push notifications, login through the same directory and reading content on weak connections, because many shift workers will never open a desktop browser. On upgrades, Nextcloud publishes a new major version every four months and supports each one for a year, and it does not allow skipping major releases. Its upgrade manual calls for one major step at a time, a backup before each step and disabling third-party apps until they are confirmed compatible. Ask XWiki and HumHub for their upgrade path in writing, including how they handle custom extensions.

Finally, compare licensing and the supported edition, since both shape long-term cost and control. Nextcloud Server is licensed under AGPL-3.0, and XWiki is licensed under LGPL 2.1, with its official Docker images under the same license. The AGPL adds obligations when you modify the software and offer it to users over a network, so have counsel review how that applies to any customized intranet. The license does not answer the support question. Nextcloud Enterprise is sold alongside the community version with a 100-user minimum, and XWiki SAS sells support, installation help and training separately. Ask each vendor who issues security fixes for the version you run, how long that version is supported and what the escalation path looks like. The right answer depends on your requirements, so score each candidate against the same written list.

How DeployOpen scopes, delivers and supports intranet selection and implementation

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For intranet requirements, that means turning this checklist into a written scope that names the platform, the audiences, the integrations and the evidence you need before any build work starts.

How we scope

Workshops to record audiences, spaces, moderation roles and mobile access needs for your organization
Written inventory of directory, SSO, document repository and search integrations, with the owner of each
Fixed-scope agreement listing deliverables and timelines, so the requirements checklist becomes a signed boundary

How we build

Install the chosen platform in your infrastructure, with directory and SSO connected to your identity provider
Configure spaces, permissions, news and moderation settings to match the requirements agreed in scope
Test access rules, search behavior and mobile access against written acceptance criteria before go-live

How we hand over

Deliver runbooks for administrators covering upgrades, backups, user onboarding and space ownership
Document configuration, integration points and the audit logs your compliance team needs to review
Transfer administration to your team with a recorded walkthrough of moderation and support procedures

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover platform upgrades that respect the vendor's one-major-version-at-a-time upgrade path
Regular review of directory changes, new spaces and access rules against the original requirements list

Intranet software requirements checklist