Why a self-hosted knowledge base for education needs different controls
A university or school IT lead usually inherits a sprawl: department wikis on shared drives, course spaces in the learning management system, staff procedures in email attachments, and a few pages that mention individual students by name. A self-hosted wiki can fit campus needs, but only when access, retention and identity are designed for education from the start. The platform choice then depends on how structured the content must be: a simple book-and-page model suits departmental procedures, while structured applications suit content with fixed fields and many contributors. Both decisions come before installation, because they determine who can see which space and what must be kept.
FERPA applies only to institutions that receive funds made available under a program administered by the US Secretary of Education (34 CFR 99.1). A private institution with no such funding may still face other obligations, so the first task is to confirm with counsel whether the institution is covered. Where it is covered, an outside hosting partner can receive education records as a school official only under the conditions in 34 CFR 99.31(a)(1)(i)(B), including direct institutional control over use and maintenance of the records. Institutions must also use reasonable access controls so that staff see only the records they have a legitimate educational interest in (34 CFR 99.31(a)(1)(ii)). A wiki that holds advising notes or disciplinary procedures therefore needs space-level restrictions, not just a shared login.
GDPR applies to processing of personal data of people in the EU, which covers students and staff at EU institutions and may cover EU students at institutions elsewhere. Wiki pages that copy student names, grades or support cases are personal data, so the institution must document a lawful basis, limit access and define how long pages stay online. Ask your data protection officer which page types may hold personal data at all, and where the wiki will be hosted, since that determines the transfer analysis. Read the text of Regulation (EU) 2016/679 with that officer rather than relying on a summary.
Which education requirements shape the wiki build
This table maps the main education and privacy rules to the access, audit, retention and vendor controls they put on a campus wiki. Read each row as a question to answer before choosing a platform, then check the wiki configuration and contracts against it. The main takeaway is that the wiki itself becomes part of the compliance scope as soon as it holds student or child data.
| Requirement | What it asks for | What it means for the wiki |
|---|---|---|
| FERPA school official access (34 CFR 99.31) | Outside contractors may see education records only as school officials under direct institutional control, with access limited to legitimate educational interests. | Create role-based spaces so staff see only records they need. Put the hosting partner under a written contract that restricts reuse of data. |
| FERPA disclosure log (34 CFR 99.32) | Record each request for and disclosure of personally identifiable information, with the parties and their interests, for as long as the records are kept. | Enable page history and audit logging. Confirm which platform audit events are retained, how long, and whether they can be exported. |
| Inspection window (34 CFR 99.10) | Comply with a parent or eligible student request to inspect records within a reasonable period, and not more than 45 days. | Ensure records about students can be located quickly across spaces, attachments and history. Test search and export before go-live. |
| COPPA for children under 13 (16 CFR Part 312) | Operators collecting personal information from children under 13 need a written security program, a designated coordinator, annual risk assessments and a written retention policy. | Pages built for K-8 or youth programs that collect names, contact details or responses need separate governance, minimal fields and a deletion schedule. |
| GLBA Safeguards Rule for Title IV institutions (16 CFR Part 314) | Institutions in Title IV aid programs must maintain a written information security program and multi-factor authentication for anyone accessing an information system. | Wiki logins for staff who handle financial aid content need MFA enforced through the identity provider or the platform, with a documented scope. |
| FTC notification within 30 days (16 CFR 314.4(j)) | Notify the FTC within 30 days of discovering a notification event affecting at least 500 consumers. | Document how wiki access logs and alerts feed the incident process, and confirm the vendor's notice timelines in the support contract. |
| GDPR personal data duties for EU institutions (Regulation (EU) 2016/679) | Define a lawful basis, limit processing to what is needed, honor data subject rights and secure processing, including with processors. | Limit personal data in pages, set retention and deletion rules for old course spaces, and confirm hosting location and processor terms. |
| Processor terms and hosting location | Processors must act on documented instructions and support security and rights obligations. Confirm specifics with counsel and the vendor. | Ask the implementation partner for a data processing agreement, sub-processor list and a description of where backups and logs are stored. |
BookStack or XWiki: which fits which campus
Both platforms cover course and department spaces, but they fit different campus needs. The choice depends on whether content stays as plain pages organized by books and shelves or needs structured applications, governed content types and connectors to campus systems.
BookStack for simple course spaces
BookStack organizes content into books, chapters and pages grouped on shelves, which maps directly to course and department spaces. It supports LDAP, SAML2 and OIDC sign-in, and multi-factor authentication can be enforced per role. Check whether faculty need only pages and attachments, because that is the scope where its structure is strongest. Confirm the PHP 8.2 and MySQL 8.0 or MariaDB 10.6 requirements against your hosting baseline.
XWiki for structured applications
XWiki's structured applications suit content that must follow a fixed shape, such as research ethics forms, program approvals or governed policy types. XWiki Pro adds Active Directory and Azure Active Directory SSO applications and connectors for Office365 and OnlyOffice. Confirm which of these applications your campus actually needs before assuming a Pro subscription, since the platform's free Standard edition covers the core wiki.
Official XWiki container variants
XWiki publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. This gives IT teams a supported container path where BookStack offers no official images and points to community setups. Decide the database engine early, because it shapes backup, upgrade and support paths. Confirm which database your central IT already operates and supports.
Choosing an LTS line
XWiki maintains a stable line, a long term support line and an intermediate LTS line. Campuses with many departments and long academic cycles usually benefit from LTS to limit upgrade frequency, but the stable line delivers newer features sooner. Ask your partner which line supports your extensions and how upgrades between lines are tested before any migration. Make the choice part of the written scope.
Licenses that change the shortlist
BookStack is MIT licensed, and XWiki Standard is LGPL-licensed with commercial support available from XWiki SAS. Outline is under the Business Source License 1.1, whose additional use grant forbids offering a commercial Document Service, so confirm the terms with counsel before a campus-wide deployment. Wiki.js 3.0 is a beta marked not for production use, so only the 2.x line belongs in a production shortlist.
Migration and extension effort
Moving existing course content from another wiki changes the decision because XWiki has a Confluence migration path through Confluence Migrator Pro, which keeps page history but not attachment history. BookStack imports and extensions are simpler but cover fewer structured features. Ask any partner to list which spaces, permissions and attachments will move, and which will be rebuilt by hand.
How campus SSO through SAML or LDAP shapes access to course and department spaces
Access to course and department spaces should follow the campus directory, not a list maintained inside the wiki. Map each wiki role to a directory group that already exists or can be created: enrolled students in a course, instructors of record, teaching assistants, department staff and administrators. BookStack documents LDAP, SAML 2.0 and OpenID Connect as primary authentication options, and XWiki Pro lists Active Directory and Azure Active Directory SSO applications, so the usual starting point is one of those protocols. Before design work begins, confirm with your identity team which attributes the campus exposes: group memberships, course or section codes, department codes, affiliation (student, faculty, staff) and account status. A group that only exists as a manually curated list will drift within a term, while a group generated from registrar or HR data will not.
Group mapping is where the design becomes concrete. In BookStack, directory groups are matched to roles, and the role then governs what a user can do on shelves, books and pages. In XWiki, the mapping is usually expressed through groups that drive page and space rights. Decide early whether a course space is readable by enrolled students only, by the whole department, or by the public, and whether course spaces are created automatically when a section is published or requested by an instructor. Test each mapping with a student, an instructor, a teaching assistant and a staff member from different departments before go-live, and confirm that a student cannot read a restricted staff space through a shared parent shelf or parent space.
Departures and graduations should be handled by changing the directory record, which then removes wiki access at the next login or sync. Ask your identity team how quickly account disablement propagates to the wiki, whether existing sessions are terminated, and whether the wiki keeps a local account that could still sign in if the directory is unavailable. Manual edits to wiki roles should be the exception and logged. Your wiki audit trail should show who was granted or removed access and when, which supports the access records a FERPA review may ask for. Confirm these behaviors in a test environment rather than relying on vendor documentation alone.
Where campus wikis should be hosted under student privacy rules
Hosting the wiki in a campus data center keeps the application, database, attachments and backups under the institution's own administrators and physical controls. This is the simplest model to explain to a registrar or general counsel, because no outside party needs access to the records to run the service. The trade-off is that the institution carries the patching, capacity, on-call and disaster recovery work itself, and staff time for those tasks must be budgeted.
- Direct control: The institution's own staff hold administrative access, so the question of who can read student pages is answered by its own access policy.
- Outside support access: If a partner later patches the server or troubleshoots a fault, it should work under the institution's direct control, with logged, time-limited access and no copies of data leaving campus.
- Backup location: Backups should be stored on campus or in a second institution-controlled site, and the retention period should be set in the same policy that governs the records.
- Access logging: Logs for who viewed or changed pages containing student information need to be retained so the institution can answer FERPA disclosure record questions.
- Network segmentation: Place the wiki on a segment that campus staff, students and remote users reach through the same single sign-on path, so no separate accounts are created.
Before committing to this model, confirm with your data protection officer and registrar who would be a school official, how backups are encrypted and where the restore copies physically reside.
Running the wiki in a cloud account that the institution owns, under its own tenancy and keys, is a middle path. The institution still controls the data and the configuration, while the cloud provider supplies facilities and hardware. The compliance question shifts from who holds the server to whether the provider's contract, region choice and administrative access model fit the institution's obligations.
- Account ownership: Administrative roles, encryption keys and audit logs should sit in the institution's cloud tenancy, with named administrators and no shared root credentials.
- Region selection: Choose a region that matches the institution's data residency commitments and any GDPR transfer analysis for students or staff located in the EU.
- Partner access: An implementation partner working in this account is an outside contractor, so the institution's agreement should limit its use of records to the service, require return or destruction at the end, and restrict redisclosure.
- Backup location: Confirm whether snapshots and replicas stay in the chosen region and who can restore them, since cross-region replication may create a second location to document.
- Provider terms: Confirm the provider's data processing terms, sub-processor list and the process for government access requests.
Ask your cloud provider and counsel to confirm the regions, key management options and sub-processor locations in writing before the wiki is loaded with student data.
A managed or vendor-hosted instance moves operations to an outside party. XWiki SAS offers XWiki Cloud hosting on ISO 27001 certified infrastructure, which is one option to evaluate alongside other managed providers. This model can reduce internal operations work, but it makes the outside party a school official for any education records it touches, which brings FERPA contract conditions into play.
- School official conditions: Under FERPA, an outside contractor may receive education records as a school official only if it performs a service the institution would otherwise use employees for, is under the institution's direct control for use and maintenance of the records, and follows the redisclosure limits.
- Access restriction: The institution should confirm that the provider's staff can access only the records needed for the service, and that access is logged and reviewable.
- GDPR transfer questions: For students in the EU or processing that falls under GDPR, ask where data is stored and processed, which sub-processors are used, and what transfer mechanism applies to any location outside the EEA.
- Backup location: Ask where backups are written, how long they are kept, and whether they can be restored to an institution-controlled location if the contract ends.
- Certification scope: An ISO 27001 certificate covers an information security management system for a defined scope. Confirm that the scope includes the hosting service being purchased, and treat it as evidence to review rather than proof of FERPA compliance.
Request the provider's certificate scope, sub-processor list and data processing terms, then have counsel confirm the contract language on school official status.
How a campus wiki rollout moves from pilot to governed spaces
The sequence takes a campus wiki from a scoped pilot to governed course and department spaces, with each phase producing a documented decision or a tested control before the next one starts. It is designed so that student-related records are kept out of spaces that were never approved to hold them.
Scope content and classify student-related spaces
The institution's records or compliance lead, the IT lead and two or three department representatives inventory the content that will move into the wiki, from course outlines and lab notes to advising guides and internal procedures. Each content category is tagged as public, internal, or student-related, and the team records which categories may hold education records under FERPA and which personal data falls under GDPR for any EU-based students. The output is a signed classification register that names which spaces may never hold student-identifiable information. Confirm with counsel whether any category needs to be treated as an education record before anyone creates a space.
Choose BookStack or XWiki against structure needs
The team compares the content model each classification requires. BookStack organizes content into books, chapters and pages grouped on shelves, which suits course handbooks and departmental guides with a simple hierarchy. XWiki fits when spaces need structured applications, custom data types or extensions such as forms and calendars, and when Confluence content needs a migration path. The team tests both platforms against three real content samples from the register, checks authentication options and confirms which features require XWiki Pro. The output is a written platform decision with the features the institution does not need, so the choice can be defended to governance.
Integrate identity and map groups in a test tenant
The identity team connects the chosen wiki to campus single sign-on in a non-production environment, using SAML 2.0, OpenID Connect or LDAP depending on the directory in use. BookStack documents LDAP, SAML 2.0 and OpenID Connect as primary options, and XWiki supports SAML and LDAP through its extensions, which the team confirms against the installed version. Directory groups for faculty, staff, students and course rosters are mapped to wiki roles, and the team tests that a student account cannot reach a staff-only space. The output is a mapping table approved by the identity owner and a test log showing each role's access.
Validate the permission model and audit logging
The security engineer builds one space per classification level and runs a permission test plan: each role attempts to read, edit and export pages in every space, and the results are compared against the register. The team also confirms that the wiki records access and changes in a form the institution can review, since FERPA requires a record of disclosures from education records and HIPAA-style audit controls are a useful model even where they do not apply directly. Multi-factor authentication for administrators is verified. The output is a signed test report with every failed case either fixed or accepted by the data owner.
Migrate existing sites and Confluence content
Where the campus already runs a Confluence site or departmental sites, the team inventories spaces, owners and attachments before moving anything. XWiki SAS offers Confluence Migrator Pro, which migrates spaces, pages, users, groups, permissions, attachments and metadata and keeps page history but not attachment history, so the team records which attachments must be archived separately. The team runs one migration on a copy, reviews permissions and broken links, and rejects any space that contains student-related records not in the register. The output is a migration report signed by the content owners, plus an archive of attachment history kept under the institution's retention rules.
Train editors and assign content owner roles
The project lead appoints a content owner for each course or department space and a wiki administrator who controls permissions and extensions. Editors receive training on the chosen editor, the classification rules, and what must never be pasted into a page, such as grades or disciplinary notes. Content owners are trained to review pages on a schedule they set, and to request access changes through a defined process. The output is a roster of named owners and administrators, a short editing standard, and a training attendance record for each person who will hold edit rights.
Go live and run the retention review
The team moves the approved spaces into production, enables the audit logging and access reviews validated in earlier phases, and sets a go-live checklist covering backups, administrator access and the support path. After go-live, the records and compliance lead runs a retention review of each space against the institution's schedule, with particular attention to COPPA when any content touches children under 13, and to GLBA where the institution's Title IV obligations apply to related systems. The output is a governance record listing each space, its owner, its classification, its retention rule and the date of the next review.
Evidence a registrar, auditor or privacy office will ask for
This table maps each piece of evidence a registrar, auditor or privacy office is likely to request to the wiki component or operating process that produces it. Read it as a checklist to design logging, permission reviews and retention before go-live, not as a statement of what any regulator requires in your case. DeployOpen prepares systems and evidence, but auditors and regulators decide whether your institution is compliant.
| Evidence | What it shows | Wiki component or process that produces it |
|---|---|---|
| FERPA disclosure record | Each request for and disclosure of personally identifiable student information from education records, with the parties and their legitimate interests, kept as long as the records are kept (34 CFR 99.32) | Wiki audit log combined with a documented disclosure process for pages containing student data; confirm with counsel whether page views or only exports must be recorded |
| Vendor school official designation | Evidence that an outside hosting or implementation party acts as a school official under direct institutional control and follows redisclosure limits | Signed contract, data processing terms and the administrator access list kept with the wiki deployment records |
| Legitimate educational interest controls | Reasonable access controls so staff see only the records they need (34 CFR 99.31(a)(1)(ii)) | Space and page permission matrix, role definitions and periodic permission reviews by space |
| Permission review by space | Who can read and edit each course, department or records space, and when that was last confirmed | Exported role and permission report per space, reviewed by the owning department and signed off on a set schedule |
| MFA enforcement records | Multi-factor authentication applied to staff who access systems holding GLBA-covered student financial data (16 CFR 314.4) | Per-role MFA enforcement settings in the wiki, directory policy records from the campus identity provider and sign-in logs for affected accounts |
| Written information security program | A written program with a designated coordinator and risk assessments, covering the wiki as an information system | Security policy page kept in the wiki with version history, named coordinator and dated risk assessment records |
| COPPA retention policy and deletion records | Where children under 13 appear in pages or uploads, a written retention period and evidence of deletion (16 CFR 312.10) | Retention schedule document, scheduled page and attachment deletion jobs or manual purge logs, and a review of K-12 pages for personal data |
| GDPR records of processing | Description of purposes, categories of personal data, recipients, retention and security measures for the wiki (GDPR Article 30) | Processing register entry for the wiki, data map of user profiles, page content and attachments, and hosting location records |
| Access and audit logs | Who viewed, created, edited or deleted content, and when, with logs protected from tampering (45 CFR 164.312(b) is the HIPAA analogue assessors often borrow) | Wiki activity log and authentication logs forwarded to a central log store with defined retention and restricted read access |
| Page history and change approval | Evidence that policies and procedures were reviewed, approved and changed in a controlled way | Built-in page revision history, approval step recorded in the page or in a linked ticket, and export of revisions for the review file |
Questions education buyers ask before hiring an implementation partner
What drives the cost of a self-hosted wiki for a university?
The cost is driven by scope of work more than by the software, which is free to download under the license terms of the platform you choose. The main cost components are the number of spaces and templates to design, the complexity of single sign-on, the volume of content to migrate, and the hosting and administration you carry afterward. If you choose XWiki and need its paid applications, XWiki SAS publishes Pro and support tiers by user count: Starter for up to 25 users (XWiki Cloud only), Basic for up to 1,000 users, Business for up to 10,000 users and Enterprise for unlimited users. Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training is listed at 1500 EUR per day. Confluence Migrator Pro is priced from 2000 EUR. Ask any partner for a fixed-scope quote that itemizes spaces, identity integration, migration volume and training days separately, and state which costs recur each year.
How long does a campus knowledge base implementation take?
The timeline depends on how many course and department spaces need structure, how many identity sources must be integrated, and how much legacy content must move. A single department on BookStack with one campus login is a much smaller project than a university-wide XWiki deployment with directory group mapping, migrated Confluence spaces and training for editors across faculties. Approval cycles with the registrar, legal and the data protection office often set the pace more than the technical work. Your partner should give a written schedule tied to the agreed scope, with milestones for identity testing, pilot spaces, migration dry runs and sign-off. Ask for the assumptions behind each milestone, especially how many review rounds are included.
What does the campus IT team need to provide for the project?
Three things determine whether the project moves: directory access, named data owners and a clear sign-off path. For directory access, the team needs a test LDAP, SAML or OpenID Connect configuration that maps campus groups such as faculty, staff and students to wiki roles, along with a service account or metadata exchange approved by identity administrators. Data owners for each department or course area must decide who can read and edit their spaces, and they should review sample pages during the pilot. Sign-off should name who approves the permission model, the migration results and the production cutover. Ask the partner to list these inputs in writing before work starts, with the person responsible for each.
Can our staff run a self-hosted wiki after the project ends?
Yes, if the team has the skills and capacity to operate it, but you should plan for ongoing work. A self-hosted wiki needs regular platform upgrades, backups, monitoring, certificate renewal, identity configuration changes when campus systems change, and support for editors. BookStack requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and its documentation points to official installation scripts for Ubuntu 26.04, 24.04 and 22.04, with community Docker setups for container users. XWiki publishes stable, long term support and intermediate LTS lines, so you can choose a release cadence your staff can sustain. Decide before the project whether internal staff, a partner under a retainer, or a mix of both will own each task, and write that split into the handover plan.
Should a school use BookStack or XWiki instead of a university?
BookStack suits organizations that want a simple hierarchy of books, chapters and pages with a fast editor, and it supports LDAP, SAML 2.0 and OpenID Connect. XWiki fits better when you need structured applications, such as forms, calendars, meeting records or department-specific data models, along with fine-grained permissions across many departments. Schools with a few teachers and a small set of subject spaces often find BookStack sufficient. Universities with many faculties, research groups and administrative units frequently need XWiki's structure and permission depth. Check whether the features you need are in the free edition or in XWiki Pro, because Active Directory SSO and several business applications are listed as Pro features. Run a pilot with your real content before deciding.
Does self-hosting remove our FERPA obligations?
No. Hosting the wiki on your own infrastructure changes where the data sits, but it does not remove your duties under FERPA. The regulations in 34 CFR Part 99 apply to any educational agency or institution that receives funds under a program administered by the US Secretary of Education. Institutions must keep a record of each access request and disclosure of personally identifiable information from education records, and must respond to inspection requests within 45 days. If an outside contractor, including an implementation partner, receives education records, it must act as a school official under direct institutional control and follow redisclosure limits. Use reasonable access controls so staff see only the records they need. Involve your registrar and counsel in the design, and ask your partner to describe how its access to production systems is controlled and logged.
Which compliance evidence does a campus wiki need to produce?
A campus wiki supports compliance evidence rather than issuing it. For FERPA, you need records of access and disclosure, role-based permissions that limit access to education records, and a documented process for inspection requests. Where the institution also falls under the GLBA Safeguards Rule through its Title IV participation, the written information security program, multi-factor authentication for anyone accessing an information system, and the FTC notification duty within 30 days for events affecting at least 500 consumers all apply. If you run the wiki for children under 13, COPPA adds a written security program and a retention policy. Ask your partner which audit logs the platform records, how long they are kept, and how you export them for your assessor. Auditors and certification bodies, not implementation partners, issue assessments.
What should be settled before signing a statement of work?
Settle the scope in writing: the list of spaces, the identity sources, the permission model, the content to migrate and the features you expect from XWiki Pro or other paid applications. Confirm who holds the licenses, who pays subscriptions and whether consulting or training days are included or billed separately. Agree how acceptance will be tested, including single sign-on login from several campus roles, restoration from a backup, and a sample of migrated pages checked against the source. Ask about upgrade and support terms after go-live. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own environment, and most engagements are fixed-scope with written deliverables and timelines agreed before work starts. A quote follows from that written scope.
What to ask an implementation partner before signing
Start with the access model, because it decides whether FERPA and GDPR obligations can be met at all. Ask how the partner maps campus groups from LDAP or SAML attributes to wiki roles in BookStack or XWiki, who approves each mapping, and how a student who leaves a course loses access to course spaces without manual clean-up. Ask them to demonstrate the test they run for school official access: a set of named test accounts (student, instructor, department staff, outside contractor) with the expected read and edit results written down before testing starts. Under 34 CFR 99.31(a)(1)(ii), access must be limited to the records a person has a legitimate educational interest in, so a passing test means each role can reach only its own spaces. Ask for the written results, not a verbal summary.
Next, ask how audit logs are kept, where they are stored, and for how long. FERPA requires the institution to record each disclosure of personally identifiable information from education records and keep that record for as long as the records are kept (34 CFR 99.32). Confirm which events the platform logs natively, which need a separate logging layer, and who in the institution can export them. Then ask for the contractor terms in writing. The partner should agree to act as a school official only where it performs a service the institution would otherwise use employees for, works under the institution's direct control for records use and maintenance, and observes the redisclosure limits in 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). Also confirm how upgrades of BookStack or XWiki are tested and rolled back, and how restores from backup are tested against a known date. Finally, ask which license terms govern the chosen platform. BookStack is MIT licensed and XWiki is LGPL-2.1-or-later, and any paid XWiki Pro applications or support subscriptions carry their own terms, which the partner should list in the quote.
How DeployOpen scopes and supports a campus wiki
This sequence turns a campus wiki idea into a written, fixed-scope engagement with a clear build, test and handover, so the institution knows what is delivered, who operates it and what evidence exists for its compliance reviews. DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside the institution's own infrastructure.
Confirm the scope and data classes with the institution
DeployOpen meets the registrar or records office, the IT identity team and the department leads who will own course and department spaces. Together they list which content is expected to hold student education records, which holds only staff material, and which pages might collect personal data about minors or applicants. The output is a written scope note that names the platform choice (BookStack or XWiki), the identity sources, the user groups and the spaces in the first release. Nothing moves to design until the institution has approved this note.
Agree a fixed-scope written statement of work
DeployOpen turns the scope note into a statement of work that lists deliverables, responsibilities, acceptance criteria and the timeline agreed for the engagement. The institution's procurement and legal teams review the document, and any data processing terms that apply under FERPA, GDPR or other rules are settled in parallel. The step is complete when both parties have signed the statement of work. Retainer terms for upgrades and support are negotiated here as a separate written agreement if the institution wants them.
Design the architecture and identity integration
DeployOpen documents the hosting design inside the institution's cloud account, data center or private network, including database choice, backup location, network segmentation and administrator access paths. It also designs campus single sign-on through SAML, OpenID Connect or LDAP, and maps directory groups to wiki roles so that course and department access follows enrollment and appointment data. The output is an architecture document and an identity mapping table that the security team can review before any build starts.
Build spaces, roles and templates
DeployOpen installs the chosen platform, creates the shelf, book or space structure for courses and departments, and configures roles so that only the intended readers and editors see each area. Where XWiki is selected, it also configures the structured applications that the institution needs for controlled content. Templates for course pages, policies and procedures are added. The step closes when a test set of accounts from each user group can reach exactly the spaces their role allows, and the results are recorded in a test log.
Harden, test and record access evidence
DeployOpen applies the hardening baseline agreed in the design, including multi-factor authentication where the institution requires it, audit logging for administrator and content access, and restricted export paths. It runs security testing against the deployed wiki, covering the web application, its APIs and the hosting layer, and reports findings with severity and remediation owners. The institution receives the test report and a list of retained logs. DeployOpen prepares these artifacts for compliance reviews but does not issue audit reports or certifications, which remain the work of independent auditors.
Migrate content and train the editors
If the institution is moving content from an existing system, DeployOpen maps spaces, pages, permissions and attachments, runs a trial migration, and checks the results against a sample of pages chosen by the content owners. Training sessions cover editors, space administrators and help desk staff. The handover is complete when content owners sign off on migrated spaces and administrators can perform backups, restores and user changes on their own, based on the runbooks DeployOpen delivers with the platform.
Hand over operations and optional retainers
DeployOpen delivers the final documentation set, including configuration records, backup and restore procedures, the access matrix and the incident contacts. The institution's operations team takes over day-to-day running, or it selects a retainer for upgrades, patching, continuous testing and support under a separate written agreement. The closing check confirms that backups have been restored successfully in a test, that the handover checklist is signed and that the institution knows which upgrade and support options apply going forward.
