Administrator handbook: security and data protection

Everything the administrator of a HumHub community hosted by CUZY should set up and keep doing to run a secure and compliant community. Written for administrators, not programmers.

Last updated: 13 September 2026. This handbook gives practical guidance; it is not legal advice. Laws differ by country and change over time: confirm the legal parts with your data protection officer or counsel.

How this handbook is organized

CUZY runs the servers, backups, updates and monitoring (see Security and reliability of CUZY Hosting). You run the community: who may join, who administers it, what members see, how long data is kept, and which legal texts apply. This handbook has three parts:

Part	Applies to	What it covers
1. Security	Every community, every country	Administrator accounts, two-factor authentication, registration and access rules, content and files, member lifecycle, custom domain and email, what to do in an incident.
2. GDPR	Communities in the EU/EEA, and any community with members in the EU/EEA	Your role as controller, the agreement with CUZY, notifications to authorities, legal pages, legal basis, records, retention, members' rights, cookies, transfers, breaches, employees, minors.
3. Outside the EU	Communities established elsewhere	Pointers for the United Kingdom, Switzerland, the United States, Canada, Australia and Brazil, and what changes when your data is hosted in the EU.

Three modules do much of the work and are available on every plan: Two-Factor Authentication (2FA), Legal Tools (legal pages and consents) and User Cleanup (retention of inactive accounts). The checklists at the end summarize the whole handbook.

Part 1: Security Applies to every community, in every country.

1. Administrator accounts

Why. Administrators can read every space, change every setting and delete every account. Almost every serious incident in a community platform starts with an administrator account.

Keep administrators few. Two or three people. Give everyone else the exact rights they need through groups and space roles instead of the administrator role. Administration → Users → Groups → Administrator.
One person, one account. No shared "admin" login. Every administrator uses a personal account so actions can be attributed and access can be removed when someone leaves.
Strong, unique passwords. CUZY enforces a minimum password policy on every community. Administrators should additionally use a password manager and never reuse a password from another service. If you want a stricter policy than the platform default, ask support.
Two-factor authentication for every administrator, see section 2.
Review quarterly who is in the Administrator group and remove people who no longer need it.
CUZY support access. Our staff can log into your community for support only through one-time links that are recorded and shown to you. You can disable this at any time. Administration → CUZY Hosting → Allow CUZY staff to log in.

2. Two-factor authentication Two-Factor Authentication module

Why. A stolen or guessed password is useless without the second factor. This is the single most effective protection for accounts.

Enable the module and require 2FA at least for the Administrator group; the module turns it on for administrators by default. Consider requiring it for all members in communities that handle sensitive information. Administration → Modules → Two-Factor Authentication → Configure.
Prefer an authenticator app (time-based codes, works with Google Authenticator, Microsoft Authenticator, Aegis and others) over email codes; email codes are better than nothing but depend on the security of the mailbox.
Plan for lost devices. Decide who may reset a member's 2FA, and how identity is verified before doing it (a call-back, an in-person check). Never reset on the basis of an email request alone.
Announce it. Tell members why and how before enforcing it for everyone; give a short grace period.

3. Registration and access rules

Why. Open registration on an internal community is the most common misconfiguration we see: anyone on the internet can join, read and post.

Administration → Settings → Authentication.

Internal communities (company, association, school): disable anonymous registration; add members by invitation, or restrict registration to your organization's email domains if your identity provider or a module supports it.
Public communities: keep registration open but require administrator approval or at least email verification, enable the captcha, and set a minimum age with the Legal Tools module (see Minors).
Invitations: decide whether members may invite others by email or by link. Invitation links can be forwarded; prefer email invitations for closed communities.
Guest access: leave it off unless you deliberately publish content to the internet. When on, review which spaces and profile fields are visible to guests (section 4).
Single sign-on: if your organization has an identity provider (Microsoft Entra ID, Google Workspace, Keycloak, SAML), connecting it centralizes password policy, 2FA and offboarding. Ask support about the available authentication modules.

4. Visibility of members and content

Why. Members trust that what they post in a private space stays there, and that their profile is seen only by the intended audience.

Default space visibility. Set the default for new spaces to private (members only) and the default content visibility to private. Space owners can still open individual spaces. Administration → Spaces → Settings.
Profile fields and the People directory. Decide which profile fields are visible to guests and to members, and which appear in the directory. Keep phone numbers and private addresses off the directory. Administration → Users → Profiles and Settings → People.
Space roles. Use the three space roles (member, moderator, administrator) rather than making everyone a space administrator.
Public content. Content marked public is visible to anyone with the link when guest access is on. Train members on the public/private switch when posting.

5. Files, links and embedded content

Why. Uploads and embeds are how malware and tracking enter a community.

Allowed file types and size. Restrict uploads to the types your community needs; executable and script files should never be allowed. Administration → Settings → Files.
Embedded content (oEmbed). Videos and social posts embedded from YouTube, Vimeo or others load content from those providers and can set their cookies. Keep the provider list short, and use the Legal Tools "external resources" warning so members know when they leave your network. Administration → Settings → OEmbed providers.
Reporting. Enable the content reporting feature and name who handles reports, so members can flag spam, abuse or leaked personal data.
Antivirus. Scanning of uploaded files is available as an add-on (ClamAV) for communities that exchange documents with external parties.

6. Member lifecycle and offboarding User Cleanup module

Why. Dormant accounts are the easiest way in for an attacker and the most common cause of data kept longer than allowed.

Leavers. When someone leaves your organization, deactivate or delete the account the same day. Deactivation keeps the content and blocks login; deletion removes the account and, if you choose, its contributions. Administration → Users → edit user.
Inactive accounts. The User Cleanup module warns members after a period without login, sends a reminder, deactivates the account, and permanently deletes it later, all with periods you choose. A member who logs in during the warning period keeps the account. Administrator accounts are never touched. Administration → Modules → User Cleanup → Configure.
Never-activated accounts. Registrations that were never confirmed can be removed automatically after a short period.
Pending approvals. Review the approval queue regularly; do not leave unknown applicants pending for months.
Sessions. When an account is suspected compromised, change the password and end its active sessions from the user's administration page.

7. Custom domain and email

Custom domain. If your community runs on your own domain, keep the domain registration renewed and its DNS account protected with 2FA; CUZY manages the certificate automatically once the domain points to us.
Sender domain. By default notifications are sent from a CUZY sending domain with full authentication (SPF, DKIM, DMARC). Business plans can send from your own domain after adding the DNS records we provide; do not add our provider to your domain without those records, or your emails will be rejected by mailbox providers.
Phishing. CUZY never asks for your password by email. Notifications always link to your community's own domain; teach administrators to check the address bar before signing in.

8. If you suspect a problem

Contain: change the passwords of the affected accounts, end their sessions, and if needed temporarily deactivate them. If an administrator account is involved, review the Administrator group immediately.
Tell CUZY through the support form in the administration or your customer account, with what you observed and when. We check the platform side (access logs, unusual traffic) and can restore content from backups.
Record what happened, when you noticed, what you did. You will need it for the breach assessment under GDPR.
Inform affected members if their data was exposed, once you understand the scope.

9. Routine checks

Monthly: approval queue, reported content, new administrators or space administrators, unusual spikes in registrations.
Quarterly: Administrator group review, 2FA still enforced, guest access still as intended, User Cleanup periods still appropriate, legal pages still accurate.
Yearly: full review with the checklists, update the records of processing, re-read the CUZY security page for changes.

11. Roles: you and CUZY

Why. GDPR assigns duties by role. Knowing yours tells you which documents you need.

You are the controller of the personal data in your community: member profiles, posts, messages, files. You decide the purposes and means.
CUZY is your processor: we host and operate the software on your instructions and never use the data for our own purposes.
Data Processing Agreement (DPA). Article 28 requires a written agreement between controller and processor. You accepted CUZY's DPA when you subscribed; the current version and its history are always available in your customer account for download. It lists our sub-processors, our security measures and how we help you with members' rights and breaches. Keep a copy with your records.
Sub-processors. We inform you before adding or replacing a sub-processor; you may object as described in the DPA.
Joint controllers. If several organizations run one community together (a federation, a project consortium), agree in writing who does what and tell members in the privacy policy.

12. Your data protection authority

Why. The general obligation to register data processing with the authority was abolished by the GDPR in 2018, but some notifications and national formalities remain, and you must know whom to contact within 72 hours of a breach.

Identify your authority (the one of the country of your main establishment) and keep its breach-notification form or portal bookmarked. Every EU/EEA authority is listed on the European Data Protection Board website.
Data protection officer (DPO). Mandatory for public authorities and bodies, for organizations whose core activity involves large-scale regular monitoring of people, or large-scale processing of special categories of data (health, religion, union membership, sexual orientation, ethnic origin, political opinions, biometric or genetic data, criminal data). Many associations and companies are not required to appoint one but may do so voluntarily. When you appoint a DPO, you must communicate the DPO's contact details to your authority and publish them (the privacy policy is the usual place).
National formalities. A few countries add their own: the United Kingdom charges an annual data protection fee to the ICO; some countries keep registers for specific processing (for example CCTV or health data) or require a national-law basis for employee monitoring. Check your authority's website once a year.
Prior consultation. Only when an impact assessment finds a high residual risk that you cannot reduce (section 15).

13. Legal pages and consents Legal Tools module

Why. Members must be informed before their data is processed (Articles 13 and 14), and you must be able to prove they accepted your terms.

Your community comes with the Legal Tools module enabled and with ready-to-adapt templates in several languages for the four pages below. Adapt them to your organization, publish them, and keep them current. Administration → Modules → Legal Tools → Configure.

Page	Who needs it	Must contain
Imprint (legal notice)	Mandatory in Germany, Austria and several other countries for any online offer of an organization; useful everywhere	Name and legal form of the organization, address, email, a responsible person, registration and VAT numbers where applicable, supervisory body for regulated professions.
Privacy policy	Everyone	Identity and contact of the controller (and DPO or EU representative if any); what data is processed and why, with the legal basis for each purpose; recipients and processors, including CUZY and its sub-processors; international transfers and safeguards; retention periods; members' rights and how to exercise them; the right to complain to the authority; whether providing data is mandatory; cookies and embedded content; automated decisions if any.
Terms of use	Everyone	Who may join, acceptable behavior and content, moderation and sanctions, intellectual property of posted content, account termination, liability, governing law.
Cookie notice	Everyone using non-essential cookies or embedded third-party content	What is set, by whom, for how long, and how to refuse. The session cookie needed to stay logged in is essential and needs no consent.

Legal Tools does the enforcement for you:

Acceptance at registration: new members must tick the terms and privacy policy before creating an account, and the acceptance is recorded.
Re-acceptance after changes: when you update a text, existing members are asked to accept the new version before continuing.
Footer links and email links to the legal pages, in every supported language.
Minimum age on the registration form (section 23).
External resources warning when members follow a link that leaves your network.

14. Legal basis and purposes

Why. Every processing needs one of the six legal bases of Article 6, named in your privacy policy and in your records.

Type of community	Usual legal basis	Notes
Company intranet or team network	Performance of the employment contract; legitimate interest of the employer for internal communication	Consent is generally not valid for employees (imbalance of power). Check national employment law and works-council rights (section 22).
Association or club	Performance of the membership contract (statutes); legitimate interest	Optional features such as photos or newsletters may need separate consent.
School, university	Public task or contract, depending on national law	Minors: see section 23.
Public community, customer or partner network	Contract (the terms of use) for the account; consent for optional features and marketing	Consent must be freely given, specific, informed and revocable; keep the record.

Write each purpose down: "internal communication and collaboration", "member directory", "event organization", "newsletter". A purpose that is not written down is a purpose you cannot defend.

15. Records of processing and impact assessment

Records of processing activities (Article 30). Mandatory for organizations of 250 or more people, and for smaller ones when processing is not occasional, involves risk, or includes special categories. A community platform is not occasional: keep the record. One entry per purpose, with: purpose, categories of people and of data, recipients (CUZY and its sub-processors, any connected tool), transfers, retention period, security measures (you can reference the CUZY security page). A spreadsheet is enough; many authorities publish free templates.
Data protection impact assessment (Article 35). Required when processing is likely to result in a high risk: for example large-scale monitoring of employees, processing of children's data at scale, health data, or profiling. Most communities do not need one, but document that you considered it. If the assessment finds a high residual risk, consult your authority before starting.
Review yearly and whenever you add a module, an integration or a new purpose.

16. Data minimization

Why. Data you do not collect cannot leak, cannot be requested, and does not need a retention rule.

Profile fields. Review the default fields and remove or make optional what you do not need (birthday, private phone, home address, gender). Never add fields for special categories (health, religion, union membership, political opinion, sexual orientation, ethnic origin) unless you have a documented legal basis and strong need. Administration → Users → Profiles.
Modules. Enable only the modules you use; each module can add data and processing. Disable what nobody uses.
Directory and search. Limit what the People directory shows (section 4).
Analytics. If you enable usage analytics, prefer aggregated statistics without individual tracking, and say so in the privacy policy.

17. Members' rights and how to fulfill them

Why. You must answer within one month (extendable by two for complex cases), free of charge, after verifying identity.

Right	How in HumHub
Access and portability (a copy of their data)	Members can download their own data from their account when the Legal Tools export feature is enabled together with the RESTful API module (profile, posts, comments, likes, files, and data of supporting modules such as calendar, files, messenger, polls, tasks, wiki). Administrators can also export member lists and content with the Export Members and Export Content modules. The export is machine-readable, which satisfies portability.
Rectification	Members edit their own profile. Administrators can edit any profile from Administration → Users.
Erasure	Delete the account from Administration → Users, choosing whether contributions are deleted or kept anonymized. Members can also delete their own account from their account settings when you allow it. Data then disappears from production immediately and from backups after the CUZY retention period stated in the DPA.
Restriction and objection	Deactivate the account (no login, content hidden from streams) while the request is examined; remove the member from optional processing such as a newsletter.
Withdrawal of consent	Members change notification and optional settings themselves; document how in the privacy policy.
Complaint	Name the competent authority in the privacy policy.

Name one contact address for these requests (a role mailbox, not a person) and log every request with dates. CUZY assists you as processor when a request needs platform-side action (for example confirming backup purge dates).

18. Retention and deletion User Cleanup module

Why. Storage limitation (Article 5) means every category of data needs a defined lifetime and a mechanism that enforces it.

Accounts. Configure User Cleanup: for example warn after 12 months without login, remind after 13, deactivate after 14, delete after 18. Choose periods that fit your purpose (an alumni network keeps accounts longer than a project team) and write them in the privacy policy and records. Never-activated registrations: delete after 30 days.
Content. Decide what happens to a leaver's posts: deletion, or anonymized retention when the content is needed by the team (knowledge base, decisions). HumHub offers both when deleting an account. Archive or delete spaces of finished projects; an auto-archive module can do it after a period of inactivity.
Messages and files. Private messages and uploaded files follow their author's account; large document collections may need their own rule.
Platform side. CUZY keeps backups for the retention period stated in the DPA and purges them afterwards; technical logs are kept briefly and never contain member content. Deleting the community deletes production data immediately and backups after the retention period.

19. Cookies, analytics and third-party content

Essential cookies. HumHub sets a session cookie to keep members logged in and a token against request forgery. These are strictly necessary and need no consent, only information in the cookie notice.
Optional cookies and trackers (analytics tools, marketing pixels) need prior consent under the ePrivacy rules. Do not add them unless you have a consent mechanism.
Embedded content. Videos, maps and social posts embedded through oEmbed load from the provider and may set their cookies before the member does anything. Limit providers (section 5) and mention them in the privacy policy; where consent is required, prefer linking over embedding.
Mobile app and push notifications. If your members use the HumHub mobile app, push notifications travel through the app publisher's push service (a sub-processor for your community); name it in the privacy policy. Push is available on Business plans.

20. Third parties and international transfers

Hosting and backups are in the EU. Some CUZY sub-processors are non-EU companies (for example payment and email delivery providers) operating under Standard Contractual Clauses; the DPA lists them and the safeguards, and you can reference it in your privacy policy.
Modules that connect to other services (Nextcloud, Mattermost, video meetings, geocoding, SMS, single sign-on) send data to those services. Each one is a recipient or processor for you: add it to your records, check its location and contract, mention it in the privacy policy.
Members outside the EU do not create a transfer problem: their data is hosted in the EU. Members inside the EU with a controller outside the EU: see Part 3.

21. Personal data breaches

Why. Article 33: notify your authority within 72 hours of becoming aware of a breach likely to result in a risk to people. Article 34: inform the affected people when the risk is high.

Know the sources. A breach can be a stolen administrator password, a member posting a confidential list in the wrong space, a lost laptop with the community open, or an incident on the platform side. CUZY notifies you without undue delay when a platform incident affects your data, with the technical facts you need for your assessment.
Assess within hours: what data, how many people, how sensitive, is it still ongoing, can it be undone (for example a wrongly shared file removed before anyone opened it).
Notify the authority within 72 hours unless the breach is unlikely to result in a risk. Notifying late is allowed with reasons; notifying nothing is what fines are for.
Inform members directly when the risk is high (credentials, financial data, sensitive categories), in clear language with what they should do.
Document every breach, even those not notified, with facts, effects and remedies (Article 33(5)).

Keep a one-page internal procedure with the contact of your authority, your DPO or responsible person, the CUZY support form, and a message template. Practice it once.

22. Employee and member communities

Works councils and staff representation. In Germany, Austria, France, the Netherlands and other countries, introducing a platform that can monitor employee behavior requires information or co-determination. Involve the representatives early, agree on what is logged and who can see it, and avoid individual activity statistics.
Private use policy. State whether members may use the community for private matters, whether private messages may be read by administrators (normally never, except under a documented procedure), and what happens to an account when someone leaves.
Transparency with members. Administrators can technically see all content of spaces they administer; say so, and keep the number of administrators small (section 1).
Associations. Member data used for the community must match the purposes in your statutes; a newsletter or publication of member lists needs its own basis.

23. Minors

Under GDPR, consent from a child for online services is valid only from the age set by each Member State, between 13 and 16 (16 in Germany and the Netherlands, 15 in France, 14 in Austria, Italy and Spain, 13 in several others). Below that age, a parent or guardian must consent.
Use the Legal Tools minimum age on the registration form and set it to your national threshold, or higher for an adult-only community.
For school communities, rely on the school's legal basis and the parental information process rather than on consent collected at registration, and involve the school's DPO.
Write for children: the privacy information must be understandable by the audience.

Part 3: Outside the EU Pointers for administrators whose organization is established elsewhere. The data is still hosted in the EU by CUZY, which is a cross-border arrangement from your point of view.

24. Country notes

Part 1 applies everywhere. Most of Part 2 is good practice everywhere, and much of it is required in some form by the laws below. This section only points to the differences; verify with local counsel.

Jurisdiction	Main law	What differs from GDPR practice
United Kingdom	UK GDPR and Data Protection Act 2018	Nearly identical to GDPR. Most organizations must pay the annual data protection fee to the ICO and register. Breach notification within 72 hours to the ICO. Transfers to the EU are permitted; the CUZY DPA and UK addendum cover the hosting.
Switzerland	Federal Act on Data Protection (revised FADP, 2023)	Similar principles; records of processing for organizations with 250 or more employees or high-risk processing; breach notification "as soon as possible" to the FDPIC when the risk is high; EU is an adequate destination. Privacy policy required; DPO ("data protection advisor") optional.
United States	No federal general privacy law; state laws (California CCPA/CPRA, Virginia, Colorado, Connecticut, Texas and others); COPPA for children under 13; sector laws (HIPAA for health, FERPA for education)	State laws apply above revenue or volume thresholds and mostly to businesses; non-profits and small communities are often out of scope but should still publish a privacy policy and honor deletion requests. COPPA requires verifiable parental consent for under-13s: set the minimum age to 13 or above. State breach-notification laws apply in all 50 states, with varying deadlines. If you host in the European Union, that is a data export from your perspective; disclose the location you chose.
Canada	PIPEDA (federal, private sector) and provincial laws (Quebec Law 25, Alberta, British Columbia)	Consent-based model with meaningful consent; breach records and notification to the Privacy Commissioner when there is a real risk of significant harm; Quebec adds a privacy officer, impact assessments for transfers outside Quebec and a privacy policy in French.
Australia	Privacy Act 1988, Australian Privacy Principles	Applies to organizations above A$3 million turnover and to some smaller ones (health, trading in data). Notifiable Data Breaches scheme: notify the OAIC and affected people for eligible breaches. Cross-border disclosure rules (APP 8) mean you stay accountable for data hosted overseas; state it in the privacy policy.
Brazil	LGPD	Very close to GDPR: legal bases, rights, DPO ("encarregado") expected for most controllers, breach notification to the ANPD within three working days. International transfers to the EU allowed under the ANPD's mechanisms.
Other countries	Various	Most modern laws (Japan, South Korea, India's DPDP Act, South Africa's POPIA, Kenya, Nigeria, Singapore's PDPA) share the same structure: a published privacy notice, a legal basis or consent, security measures, rights of access and deletion, breach notification, and rules for cross-border transfers. Following Part 2 puts you in a good position; check registration duties and transfer conditions locally.

Members in the EU. If your organization is outside the EU but the community is open to people in the EU, GDPR applies to that processing, you may need to appoint an EU representative (Article 27), and Part 2 applies in full.

25. Checklists

Before opening the community

Two or three named administrators, each with a personal account and 2FA enforced (Two-Factor Authentication module).
Registration mode chosen: invitation only, approval, or open with verification and captcha.
Guest access off, or deliberately on with reviewed visibility.
Default space and content visibility set to private.
Profile fields reviewed; no special categories; directory visibility set.
Allowed file types and maximum size set; oEmbed providers limited.
Legal Tools: imprint, privacy policy, terms and cookie notice adapted and published; acceptance at registration on; minimum age set.
User Cleanup periods configured and stated in the privacy policy.
CUZY DPA downloaded and filed; sub-processors copied into your privacy policy.
Records of processing written; DPIA need assessed; DPO appointed and communicated to the authority if required.
Breach procedure written, authority contact bookmarked, message template ready.
Works council or staff representatives informed where applicable.

Every quarter

Administrator group reviewed; leavers deactivated or deleted.
Approval queue and reported content handled.
2FA still enforced; guest access still as intended.
New modules or integrations added to the records and privacy policy.

Every year

Legal pages re-read and updated; members re-accept if changed.
Records of processing and retention periods reviewed.
Authority website checked for new national formalities; DPO details still correct.
Requests and breaches log reviewed; lessons applied.
CUZY security page re-read for changes in measures or sub-processors.