Open source intranet for education

Open source intranet for education: why campus spaces need different rules

If you are a registrar, CIO or communications lead running staff and campus news across faculties or schools alongside an LMS and student systems, the design of your intranet is driven by who can see what more than by its feature list. Student and minor data pulls the access model in a different direction from a corporate intranet, and FERPA's school official rules shape who may see education records at all. The usual open-source candidates for this job are HumHub, for social spaces and news, and XWiki, for structured pages and policy content, with Nextcloud often added for files. The intranet is not the LMS, and it should not become a store of student records by accident. Grades, advising notes, disciplinary matters and enrollment details belong in the systems built to hold them. The risk appears when a faculty space holds a spreadsheet of student names, a wiki page quotes an individual's accommodation, or a comment thread discusses a named student. FERPA's regulations (34 CFR Part 99) require institutions to keep a record of each disclosure of personally identifiable information from education records, and they limit school official access to those with legitimate educational interests. An intranet that quietly collects such content falls outside those records and controls. Before choosing a platform, map which content types may appear in which spaces, then decide who can create, edit and view each one. Confirm with your counsel and privacy office whether any campus community includes children under 13, because the COPPA Rule (16 CFR Part 312) adds written security program and retention duties for operators collecting that data. Ask each candidate vendor which permissions models and directory connectors its edition supports, and test them with real role groups before rollout. Plan a periodic review of spaces and attachments, since content drifts toward sensitive use over time.

Which education rules shape the intranet build

This table maps the US education and safeguarding rules most likely to touch a campus intranet to the build decisions they drive: spaces, identity, logging and retention. Read each row as a question to settle with counsel and your registrar before the design is fixed. The main takeaway is that FERPA and the GLBA Safeguards Rule shape access control and logging more than the choice of platform does.

Requirement	What it means for the campus intranet	Evidence to keep
School official exception (34 CFR 99.31(a)(1)(i)(B))	A hosting partner or contractor with access to student records must perform a service staff would otherwise do, stay under the institution's direct control, and follow redisclosure limits. Put this in the contract before any student data reaches intranet spaces.	Signed agreement, scope of service, named administrators with direct control
Legitimate educational interest (34 CFR 99.31(a)(1)(ii))	Use reasonable access controls so staff see only the spaces and records tied to their role. Faculty-wide or school-wide spaces must not expose advising notes, disciplinary files or grades to unrelated staff.	Group-to-space access matrix, quarterly access reviews, documented exceptions
Disclosure record (34 CFR 99.32)	Each request for, and disclosure of, personally identifiable student information must be recorded with the parties and their interest. Intranet downloads, shared links and exported pages that contain student data need to feed that record.	Audit log retention matched to record retention, export and link-sharing logs
Access requests within 45 days (34 CFR 99.10(b))	Parents and eligible students can ask to inspect records, and the institution must respond within a reasonable period and no more than 45 days. Find every intranet location that holds a student's data before a request arrives.	Searchable inventory of spaces and attachments that hold student data
COPPA for children under 13 (16 CFR Part 312)	School districts with elementary or middle school intranet features, student portals or accounts may collect data from children under 13. Confirm which operator duties apply to your vendors and whether the district or the vendor acts as the operator, and limit collection to what the purpose needs.	Written information security program, data retention policy with deletion timeframe, annual risk assessment
GLBA Safeguards Rule via Program Participation Agreement (16 CFR Part 314)	Institutions in federal student aid programs agree in their Program Participation Agreement to follow the Safeguards Rule. Financial aid staff spaces and aid documents on the intranet fall within a written information security program that covers the intranet.	Written information security program, risk assessment, scope that names the intranet and its hosting
Multi-factor authentication (16 CFR 314.4(c)(5))	The rule requires MFA for anyone accessing any information system holding customer financial information. Single sign-on to the intranet should enforce MFA for staff reaching aid or student financial spaces, and the identity provider should be in scope.	MFA enforcement settings in the identity provider, exception list, enrollment records
Consequences of non-compliance (34 CFR 99.67)	If an institution fails FERPA, the Secretary may withhold payments, issue a cease and desist complaint or end funding eligibility. Treat the intranet as part of the FERPA compliance scope, not a side tool, so misconfigured spaces do not become a funding risk.	Board-visible compliance owner, incident and correction procedure, periodic review of space permissions

Which data lands on the intranet and which must stay in the LMS and SIS

Staff directory content is the most common reason an education intranet starts to hold personnel data it was never designed for. Names, job titles, office locations, department memberships and work contact details are normal directory content and suit the intranet well. Employment records, salary, leave, disciplinary matters, performance notes and medical accommodations belong in the HR system of record, with access limited to HR staff and the employee concerned. Whether an intranet profile field is a sensitive personnel record depends on what the institution collects and why, so the owner of the data should decide that before fields are added.

Directory fields: Keep name, title, unit, office and work contact details in the intranet profile, synced from the directory rather than typed in by hand.
HR-adjacent data: Leave, payroll, disciplinary and health information stays in the HR system, with the intranet linking to policies rather than copying outcomes.
Staff-only spaces: Staff-only areas that hold personnel procedures need their own access rules and should not inherit a broad campus-wide audience.
Profile fields: Avoid free-text fields that invite staff to post personal details, and confirm which fields the directory already governs.
Searchability: Confirm whether search results expose profile fields to students or external users.

Before launch, ask the HR and records owners to sign off on the list of profile fields and on which spaces may hold any personnel-related content.

Which platform fits a campus intranet: HumHub or XWiki

A campus intranet usually needs two things: a social layer for faculties, departments and student life, and a structured layer for policies, procedures and restricted knowledge. HumHub and XWiki cover these differently, and Nextcloud and the LMS sit beside both, so the choice depends on which layer carries the most weight.

HumHub for faculty communities

HumHub fits social spaces, news streams and per-faculty or per-school communities where staff and students post, comment and follow updates. Each faculty can own its space while the university keeps one login and one set of content rules. Before committing, confirm with the vendor which LDAP and SAML capabilities require a paid edition, since campus directory integration depends on it.

XWiki for policies and page rights

XWiki suits structured knowledge such as academic regulations, examination policies and handbooks, where page-level access rights matter more than activity streams. A records office or registrar can restrict a page to a named group while the rest of the campus reads it. Check that your required rights model maps onto XWiki groups before you migrate existing content.

Docker variants and release lines

The official XWiki images run on Tomcat with MySQL, PostgreSQL or MariaDB variants. Choose the stable line for new deployments or the LTS line when campus IT needs a longer patch window, and plan upgrades against the release cadence your change board accepts. Confirm which database your existing campus services already operate so the image variant matches your support skills.

Directory and SSO in XWiki Pro

XWiki Pro lists Active Directory and Azure Active Directory SSO applications, which matters when campus identity lives in Microsoft directories. Open-source OpenID Connect extensions exist as community contributions, so have your identity team verify the exact authentication flow, group mapping and student account handling in a test environment before production. Ask the partner which option they will support under your subscription.

Nextcloud as the file layer

Nextcloud handles shared files, lecture materials and research data beside either platform, so neither HumHub nor XWiki has to store large documents. Link files into spaces and pages rather than duplicating them, and set retention and access per folder. Decide early which system is the source of truth for each document type to avoid conflicting copies.

Coexisting with the LMS

The learning management system keeps course content, grades and enrolment, so the intranet should link to courses instead of copying them. Map which records are education records under FERPA before you expose any student information in spaces or wiki pages. Agree on single sign-on order, notification ownership and who moderates course-related discussions.

Integration points that keep student data out of social streams

Four integration points decide whether student records stay in the systems built to hold them and out of intranet posts. Each one sets a boundary: who signs in, who sees which space, how student data is linked from its source system, and how access is logged and kept. Check all four before the first space is created.

Identity and SSO with the campus directory

Connect HumHub, XWiki or Nextcloud to the campus directory so staff and students sign in with credentials the institution already governs. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so confirm which protocol and edition your HumHub and Nextcloud setup needs before you scope the work. Map directory groups to intranet roles and keep student accounts out of staff-only spaces. Where the Safeguards Rule applies, multi-factor authentication for every information system user must be enforced, so apply it once at the identity provider.

Space permissions per faculty or school

Model each faculty, school or department as its own space with named administrators for each space. Bind membership to directory groups so that a transfer or graduation changes access without an administrator editing the intranet by hand. Keep student-facing spaces, such as course cohorts or clubs, apart from staff spaces that hold personnel or grievance material. Test the boundary with a user from each group before launch, since access controls are only as reliable as the group data behind them. FERPA expects institutions to use reasonable technical access controls so that school officials see only the education records in which they have a legitimate educational interest.

LMS and SIS deep links

Link from the intranet to the learning management system and student information system, and keep grades, enrollment and attendance in the source system. A deep link to the source record lets the source system enforce its own access rules and keep its own audit trail. Confirm with each vendor which link format and single sign-on method the product supports. If an integration must move records, treat the connector vendor as a school official only when it performs a service the institution would otherwise use employees for and stays under the institution's direct control, with redisclosure limits under 34 CFR 99.33(a).

Logging and retention settings

Turn on access and change logging for every space that holds student-related material, and decide retention before content builds up. FERPA requires institutions to keep a record of each disclosure for as long as the records are kept, including the parties involved and their legitimate interests. Set retention periods for news, comments and uploaded files, and confirm that backups follow the same rules. Institutions must comply with inspection requests within a reasonable period and not more than 45 days after receiving them, so ask the vendor how logs can be searched by student.

How a campus intranet rollout moves from pilot to governance

The sequence starts with agreeing who the intranet serves and which data it may hold, proves identity and spaces on one pilot faculty or school, and then scales with migration, training and clear ownership of upgrades and backups. Each phase closes with a written output that the next phase depends on.

Scope audiences and data classes
The institution's data protection lead, registrar or records office, IT and the faculty or school administrators agree who the intranet serves, including staff, contractors, and any student-facing areas. They also classify the content that will appear on the intranet, separating public notices, internal policy, staff working files and anything that contains education records or personal data about students under 18. DeployOpen maps these classes against the FERPA duties that apply to the institution, such as school official access and access logging, and against any GLBA Safeguards Rule or COPPA obligations the institution has identified for its own systems. The output is a signed scope document listing audiences, data classes, prohibited content and the named owner for each space category. The step is done when no space is proposed without a data class and an owner.
Integrate identity on a pilot faculty
Choose one faculty or school with a motivated administrator and a manageable user group, then connect the intranet to the campus identity provider or directory for single sign-on. The team confirms which HumHub or XWiki edition supports the directory and SSO protocols the campus uses, because this is an edition question to verify with the vendor before build starts. Group membership from the directory drives access, so that staff only see spaces their role allows. The pilot also tests account provisioning and deprovisioning when someone leaves or changes role. The output is a working login for pilot users, a documented group-to-space mapping, and a test record showing that a user removed from the directory loses access. The step is done when access follows directory changes without manual edits.
Design spaces and moderation rules
With the pilot faculty, the team builds the space structure: one space per faculty or school, sub-spaces for departments or committees, and a small set of shared spaces for campus-wide notices. For each space, the team sets who can post, who can moderate, what content is forbidden, and how restricted spaces are kept away from broad audiences. Moderation rules cover student personal information, admissions and disciplinary matters, and any reference to a named student. The output is a space register with owners, posting rights, moderation contacts and a short escalation path for content that breaches the rules. The step is done when the pilot faculty's administrator has walked through the register and signed it off.
Migrate content from legacy portals
The team inventories the existing portal, shared drives and document repositories, then sorts content into keep, rewrite, archive and delete. Records that fall under the institution's retention schedule move with their metadata and access rights, and superseded policies are archived rather than copied as live pages. Migration runs first on the pilot faculty, with a comparison of page counts, attachments and permissions before and after. Retention requirements for records that the institution must keep, and deletion timeframes for personal data it no longer needs, are confirmed with the records office before any bulk move. The output is a migration log, a reconciliation report for the pilot, and a sign-off from each content owner. The step is done when the pilot content matches the inventory and the legacy portal has a dated read-only status.
Train staff and set governance
The team runs role-based training for space owners, moderators and general staff, covering posting rules, what personal data must stay out of the intranet, how to report a problem, and how to request access to a restricted space. Training material is written for the campus, and the institution's own policy language is used rather than generic examples. A governance group made up of IT, data protection, the registrar or records office and faculty representatives meets on a regular schedule set by the institution to review access requests, moderation incidents and the space register. The output is a trained moderator list, a published governance charter, and a log of the first review cycle. The step is done when moderators can show they have applied the rules to a live post.
Hand over upgrades and backups
Before the rollout extends beyond the pilot, DeployOpen and the institution's platform team agree in writing who performs each recurring duty: backups and restore tests, security patching, version upgrades, module updates, log retention for access records, and the checks on the directory connection. The handover includes runbooks, the restore procedure, a tested recovery of the pilot environment, and the contact path for incidents. Any ongoing support, upgrades or continuous testing are arranged as a separate retainer, and the scope of that retainer is agreed in writing. The output is a handover pack and a completed restore test recorded in the operations log. The step is done when the institution's own staff can run the routine tasks from the runbook without DeployOpen present.

Evidence auditors and the Department of Education ask for

This table maps each piece of evidence an assessor or Department of Education reviewer typically asks for to the FERPA rule it supports and the intranet component that produces it. Read it as a checklist to agree with your auditor before configuration starts, since the exact evidence set depends on your institution's scope. DeployOpen prepares these systems, controls and records for assessment, but independent auditors issue any audit report.

Evidence item	Rule it supports	Component that produces it
Access logs for staff and student spaces	34 CFR 99.31(a)(1)(ii): access limited to legitimate educational interests, with reasonable technological controls	Intranet audit log, reverse proxy logs and directory authentication logs, exported to a central log store
Disclosure records for each request and disclosure of PII	34 CFR 99.32: record of requesting party and legitimate interest, kept as long as the records are kept	Access request workflow records and a disclosure register maintained by the registrar or privacy office
Outside contractor and school official designation	34 CFR 99.31(a)(1)(i)(B): direct control and redisclosure limits for contractors	Signed contractor agreement, role assignments in the intranet and the list of administrators with access to student data
Written information security program	16 CFR 314.4 under GLBA Safeguards Rule, which Title IV institutions agree to in their Program Participation Agreement	Documented program covering scope, risk assessment, designated coordinator and review cadence, stored with the intranet runbooks
MFA configuration evidence	GLBA Safeguards Rule requirement for multi-factor authentication for anyone accessing an information system	Identity provider policy exports, enforced MFA settings in the intranet SSO configuration and sample login records
Retention and deletion settings	34 CFR 99.32 retention of disclosure records, and 16 CFR 312.10 retention limits where children under 13 are involved	Documented retention schedule, scheduled deletion jobs and deletion logs for accounts and content
Breach notification readiness	16 CFR 314.4(j): FTC notification within 30 days for events affecting at least 500 consumers	Alert rules on access logs, incident runbook and contact list maintained with the security team

What do education IT teams ask before hiring a partner?

What drives the total cost of an education intranet on HumHub or XWiki?

The cost splits into one-time work and recurring work. One-time work covers discovery, space design per faculty or school, single sign-on setup with campus identity, theming, content migration and staff training. Recurring work covers hosting, patching, backups, upgrades and moderation time. The biggest swing factors are the number of spaces, how much legacy content must move, and how many identity sources must be connected. If you plan to use XWiki Pro, its subscription tiers are priced by user count: Starter covers up to 25 users and is cloud only, Basic covers up to 1,000 users, Business up to 10,000 and Enterprise is unlimited. XWiki SAS states that cloud and on-premises pricing is the same. Ask any partner for a fixed-scope quote that separates one-time implementation from annual licensing and support.

How long does it take to get a pilot intranet running for one faculty?

A pilot's timeline depends on three things: how quickly the institution confirms its requirements, how many identity and directory connections the pilot needs, and whether the hosting environment already exists. A single-faculty pilot with one identity source and a small set of spaces moves faster than a district-wide rollout with multiple student information sources. Ask the partner to break the timeline into discovery, build, pilot with a named user group, and go-live, and to state which of those steps depend on your team. Timelines should be written into the agreed scope before work starts, not estimated informally in a first call.

What does the institution need to supply before implementation starts?

Most delays come from missing inputs rather than from the software itself. Expect to supply access to a hosting environment or agree on one, a named technical contact for identity and directory, a list of faculties or schools with their space owners, a decision on which existing documents or wiki content will migrate, and a sign-off owner for data protection questions. You will also need to confirm how campus identity is structured, including which groups map to staff, students and guests. A good partner will publish this list in writing during discovery so the responsibilities are clear before the build starts.

Can our IT team run an education intranet after the handover?

Often yes, but only if the operating model is defined before handover. Running the platform involves patching, backups, restore testing, certificate renewal, identity connector checks and version upgrades, plus moderation and space administration by staff. Small teams usually need a documented runbook, a defined upgrade cadence and a support route for incidents. Ask whether the partner will document the setup in your environment, train named administrators, and offer a retainer for upgrades and testing if your team lacks capacity. The right split depends on how many staff you can release for platform work.

Does FERPA apply to an intranet that holds student data?

FERPA applies to educational agencies and institutions that receive funds under a program administered by the US Secretary of Education, and the rules govern personally identifiable information in education records. An intranet becomes in scope when it stores, displays or shares those records, for example student grades, advising notes or disciplinary details posted to a space. Under the regulations, a contractor may receive records as a school official only under direct institutional control, and the institution must use reasonable access controls so staff see only records they have a legitimate educational interest in. The institution must also log disclosures. Confirm with counsel which content is in scope and keep it out of broad spaces. The regulations are at 34 CFR Part 99.

When does COPPA apply to a school intranet or student portal?

COPPA applies to operators that collect personal information from children under 13, so it matters when a school intranet or student-facing space is open to younger pupils. The amended COPPA Rule requires a written information security program with a designated coordinator and at least annual risk assessments, plus a written data retention policy with a deletion timeframe. Many school districts find that the intranet is staff-only and COPPA does not apply directly, while a separate student portal does. Decide the audience first, then map which data each space collects. Your legal team should confirm the scope, and the rule text is at 16 CFR Part 312.

How does the intranet work alongside our LMS and single sign-on?

The intranet and the learning management system should share identity but keep distinct roles. Single sign-on through your campus identity provider lets users move between the two without separate logins, and group claims can control which spaces and courses each person sees. Keep course content and grades in the LMS, and use the intranet for faculty news, policy pages, committee spaces and staff collaboration. Link to LMS resources rather than copying student records into wiki pages. Ask the partner to test group mapping, logout behavior and session timeouts with your LMS before go-live, and to confirm which edition supports the identity protocols you need.

Which parts of the intranet need the highest data protection effort?

The highest effort goes to spaces that could hold education records, safeguarding information, health details or staff personnel files. Those spaces need restricted membership, audit logging, and clear rules about what may be posted. The GLBA Safeguards Rule also matters where an institution participates in Title IV programs, because it requires a written information security program and multi-factor authentication for anyone accessing an information system. Plan a data classification exercise during discovery, decide which content stays in other systems, and ask the partner how they will test access controls before pilot users arrive. The Safeguards Rule text is at 16 CFR Part 314.

What to ask an implementation partner for a campus intranet

Start with FERPA experience, because it determines how the partner handles student records that may surface on an intranet. Ask for named examples of work where a contractor was treated as a school official under 34 CFR 99.31(a)(1)(i)(B), and ask how they would show direct institutional control over the use and maintenance of those records. Ask how access is restricted to legitimate educational interests, which technical access controls they would configure (for example, space membership, group-based permissions and audit-visible role grants), and how they would keep the disclosure log that 34 CFR 99.32 requires. Ask who answers a parent's or eligible student's inspection request within the 45-day limit in 34 CFR 99.10(b), and how the intranet would supply that information quickly. Next, ask how the partner handles minors and COPPA. Any space or profile that a child under 13 could reach, such as a school district intranet with parent-facing content, brings the COPPA Rule into scope. Ask whether the partner has designed a written information security program with a designated coordinator, how they would support the annual risk assessment described in 16 CFR 312.8, and how deletion timeframes would be enforced for accounts and content. Then ask about campus SSO: which identity protocols they will configure against the campus directory, how multi-factor authentication is enforced for every staff account to match the GLBA Safeguards Rule in 16 CFR Part 314 where the institution is in scope, and whether the SSO setup is tested for account deprovisioning when a student or employee leaves. Finally, ask about logging, the LMS link and operations. Request a written logging design that states what is recorded, where it is stored, how long it is kept and who can read it, and ask how it supports the audit controls in 45 CFR 164.312(b) if the campus also runs health services. Ask how the partner would deep-link from HumHub or XWiki to the LMS without passing student data in URLs, and which directory edition they require for LDAP or SAML, since XWiki Pro lists Active Directory and Azure Active Directory SSO applications and the edition needed for each connector should be confirmed in writing. Close by agreeing in the scope who performs upgrades, tests backups and restores, and owns patching of the intranet and the LMS integration.

Where campus intranets typically go wrong

Most campus intranet problems do not come from the software. They come from unclear ownership of spaces, identities and data classes that build up as faculties, departments and schools change over time. The cards below describe the failure modes we see most often and what to check before launch and during each reorganization.

Student records in open spaces

A grade report, disciplinary note or accommodation letter is pasted into a space that every staff member, and sometimes every student, can read. Under FERPA, education records may be disclosed only to school officials with a legitimate educational interest, and the institution must use reasonable access controls to enforce that. Check that no space or page template is intended for personally identifiable student data, and that the intranet's default visibility is set to restricted rather than campus-wide.

Unmanaged guest and contractor access

Visiting researchers, alumni volunteers and vendor consultants are often added as ordinary accounts and never removed. A contractor who receives education records is only a school official if the institution keeps direct control over how those records are used and maintained, so an unmanaged external account can create a disclosure problem. Ask who approves guest accounts, how they expire, and which spaces they can reach.

Duplicate identity stores

Campus intranets often end up with a local user table, a separate staff directory and a student information system login, each with different names and lifecycles. When a student graduates or a lecturer leaves, the account may survive in one store and disappear in another. The GLBA Safeguards Rule requires multi-factor authentication for anyone accessing any information system, so every extra identity store is another place where that control must be enforced. Confirm which directory is the source of truth and how deprovisioning reaches the intranet.

Orphaned spaces after reorganization

When a faculty merges, a school is renamed or a department moves, its intranet spaces keep their old owners, members and student-facing pages. Those orphaned spaces often still hold personal data, and nobody is responsible for reviewing them. Assign a named owner to every space, set a review date for each one, and include space ownership in the procedure for academic restructuring.

Retention rules applied to nothing

Campus teams keep old announcements, course pages and forum threads indefinitely because no one has defined how long each content type should exist. For student-related data, FERPA requires a record of each disclosure, and COPPA operators may keep children's personal information only as long as reasonably necessary and must maintain a written retention policy. Ask the registrar and legal office to set deletion timeframes per content type before the intranet holds live student content.

How DeployOpen scopes and supports a campus intranet

DeployOpen starts every campus intranet engagement with a fixed-scope agreement in writing. Before work begins, the scope, deliverables and timelines are agreed in that document, so the university or school district knows exactly which faculty or school spaces, identity integrations, LMS touchpoints and migration steps are included. Ask the partner to list each faculty or school space, each directory or SSO connection (for example, the campus identity provider and any LDAP or SAML settings your edition needs), and each system the intranet must sit beside, including the LMS. Anything not written into the scope should be treated as a separate, quoted change.

The platform is deployed in the institution's own infrastructure: its cloud accounts, data center or private network. Student and staff records, profiles and space content stay under the institution's control, which matters for the FERPA direct-control and access-control expectations covered elsewhere on this page. Confirm where backups are stored, who holds administrator credentials, and how the partner's staff access the environment during hardening, upgrades and support. DeployOpen also runs security testing of the applications and APIs involved, and prepares systems, controls and evidence for compliance readiness. It does not issue audit reports or certifications; the institution's independent auditors and certification bodies do that work.

Ongoing work after go-live is covered by retainers for upgrades and ongoing support, which are separate from the initial fixed-scope project. Plan for recurring effort in module and platform updates, security patching, backup checks, administrator changes when staff or student cohorts turn over, and periodic testing. Ask the partner to describe the upgrade cadence, response expectations and which activities the retainer includes, and to put them in writing before signing. Because DeployOpen does not publish a price list, the quote should show one-time project work separately from the recurring retainer.

Open source intranet for education