Policies and Standards Access management, audit logging, encryption, and transparency. Adapted from GitLab's Security and Technology Policies. Access Management Policy Access Management Policy Adapted from GitLab's Access Management Policy. Purpose and scope Make sure only the right people have access to NFE systems and data, with no more access than they need. This covers Nextcloud, mail, LDAP, BookStack, ERPNext, Plane, servers, cloud and DNS accounts, and field devices (meters, inverters, edge computers). Principles Least privilege: give the minimum access needed for the role. Admin rights are the exception, not the default. Need to know: sensitive data (customer, financial, personal, credentials) is shared only with people whose work requires it. Unique accounts: one person, one account. No shared logins except documented service accounts. Strong authentication: 2FA wherever the system supports it. Required for admins. Service accounts and API keys (e.g. MCP Server , claude-api , cli ) each have an owner, a purpose and the narrowest scope possible. They are listed in the access register. Granting access The person's lead or the Security DRI approves access, and it is recorded in the access register (a Nextcloud spreadsheet in the Security folder; to be created). Admin access needs approval from the Security DRI. Reviews Every quarter , the Security DRI reviews: members of the Nextcloud admins group and other privileged groups; every user's app passwords and sessions (each person checks their own; admins check service accounts); accounts of people who have left; field-device and server SSH keys. Access that's no longer needed is removed. Each review gets a dated note in the Library. Removing access When someone leaves or changes role, access is removed the same day; see Onboarding and Offboarding Access . Exceptions Exceptions need written approval from the Security DRI, recorded with a reason and an end date. Audit Logging Policy Audit Logging Policy Adapted from GitLab's Audit Logging Policy. Why We can only investigate what we logged. In the 2026 mailbox incidents, the login and source-IP evidence had already gone from Nextcloud's activity stream (it kept about 6 months), and mail submission headers don't record the sender's IP. This policy closes that gap. What must be logged System Events Owner LDAP / mail (Postfix, Dovecot) Successful and failed logins with username, source IP and time; messages sent per authenticated user Federated Computer Roundcube Logins ( userlogins log) with IP Federated Computer Nextcloud Logins, failed logins, app-password and 2FA changes, admin actions, sharing (the admin_audit app) Security DRI BookStack, ERPNext Logins and admin changes (built-in audit logs) System owners Servers and field devices SSH logins, sudo use, config changes Tech lead Retention Keep security logs for at least 12 months , so an incident found months later can still be investigated. Logs must be protected from changes and readable only by admins. Review and alerts Alert when one account sends unusually many messages per hour, or logs in from a new country. The Security DRI checks failed-login and sending-volume summaries monthly, and DMARC aggregate reports (sent to admin@) monthly. Status As of October 2026, retention and alerting are not yet confirmed with Federated Computer. That is an open action from the 2026 incident report. Encryption Standard Encryption Standard Adapted from GitLab's Encryption Policy. In transit Every NFE web service (Nextcloud, BookStack, ERPNext, webmail) uses HTTPS with TLS 1.2+ . Plain HTTP only redirects to HTTPS. Mail clients connect with TLS (IMAPS 993, SMTP submission 587 with STARTTLS or 465). Never with plain-text auth. Field devices report over encrypted channels: TLS for MQTT, a VPN or tunnel (WireGuard/Tailscale) for remote admin. Modbus/TCP has no encryption, so it must stay on local networks or inside a tunnel. At rest Laptops: full-disk encryption on (FileVault / BitLocker / LUKS). Phones: device encryption with a screen lock (the default on modern phones). USB drives and backups holding NFE data: encrypted. Server disks and backups: encrypted by the host. Confirm with Federated Computer. Secrets Passwords, API keys, tokens and private keys are kept in a password manager or the system's own secret store. Never in Library pages, Deck cards, chat, email, code repositories or unencrypted files. Rotate a secret straight away if it may have been exposed; see Leaked Credentials Runbook . Use modern algorithms: RSA ≥ 2048 or Ed25519 for keys; never MD5 or SHA-1 for security purposes. Transparency by Default Transparency by Default Adapted from GitLab's "Transparency by Default" for Security. Openness is one of NFE's values. In security, being open about how we work, what went wrong and what we changed makes the whole team stronger. Hiding incidents means repeating them. What we share openly (inside NFE, in this Library) Our security policies and how-tos (this book). Incident reports once the incident is closed: timeline, root cause, lessons and actions. Results of access reviews and security checks (summarised). What we keep confidential Passwords, keys, tokens and anything that would help an attacker right now (unpatched weaknesses, exact firewall rules). These go in the password manager or a restricted folder. Personal data of customers, team members and partners. Details of an incident while it is still being handled , shared on a need-to-know basis. Partner or funder information shared with us in confidence. Writing incident reports Blameless: describe what happened and why the system allowed it, not who to blame. Remove secrets, and anyone's personal data beyond what's needed. Include what is still unknown , and clear actions with owners. Sharing outside NFE Security information goes outside NFE (to customers, funders, the public) only with approval from the Security DRI and a director. If customer data was exposed, we may be legally required to notify the people affected.