Documentation · guide 10 of 10
Security and privacy, for your IT and data-protection review
This is docs/10-security-for-it-reviews.md, one of the ten guides that ship inside the AlumDeck zip under docs/, as written for release 2.0.0. The same guide opens inside the admin, from the ? link in a screen's header or from System, Help.
Institutions often send a security questionnaire before a new system goes live. This guide gives the answers for AlumDeck in three parts: a security summary, answers in the style of a HECVAT Lite, and a data processing agreement template. Everything here describes what the code does; where something is not done, it says so. The detailed code review of release 2.0.0, with every finding and its status, is Security review.
The vendor is Cerevonix FZ-LLC, and the answers about the company are ours. Lines marked For your IT to fill in depend on your hosting, so only you can answer them.
Part 1 - Security summary
What AlumDeck is, and where the data lives
AlumDeck is self-hosted: you install it on your own hosting, on your own domain, with your own MySQL or MariaDB database. Member data never reaches the vendor. It is stored only in your database and your upload folders, on a server you choose and control.
What leaves your server by default is the licence check: about twice a day the site sends its licence key, its address and a one-time random number to the vendor's licence server, and nothing about your members. The answer is signed by the vendor (Ed25519) and the site checks the signature against two public keys that ship with it. A site that cannot get an answer keeps its public pages, but pauses signing in 21 days after installation if it has never had one, or 81 days after its last answer (a warning banner shows for the last 21). Checking for new versions is a separate switch, off by default; when on, it also sends the version number.
If Cerevonix ever stops trading, we will publish a final release of AlumDeck that runs without the licence check.
Everything else that talks to another service is an integration an administrator switches on and configures with the institution's own account: outgoing email (your SMTP server or the server's own mail), Cloudflare Turnstile, Google Analytics, Google Tag Manager, the Meta pixel and the LinkedIn Insight Tag (each waits for the visitor's cookie consent by default), online payments (Stripe, PayPal and the other supported providers), text messages and WhatsApp, web push, social sign-in and institutional single sign-on (SAML 2.0, OpenID Connect, CAS), a map geocoder, an AI writing assistant, a REST API with outgoing webhooks, and an MCP endpoint for AI assistants. All of them are off on a new install. Each one is a contract between your institution and that provider; none of them passes through the vendor.
Controls in the software
| Area | What AlumDeck does |
|---|---|
| Transport | Runs over HTTPS when the site address is https. Sends HSTS (two years, this host only), and the session cookie only over HTTPS. |
| Passwords | At least 12 characters for every account. Stored as bcrypt hashes (Laravel's default). Reset links are single-use and expire. |
| Staff sign-in | Two-factor sign-in is required for everyone with admin access: an authenticator app (TOTP) or an emailed code. Eight wrong codes lock that account's second step for 15 minutes, and the administrators are told. |
| Sessions | Encrypted at rest, httpOnly, SameSite=Lax. Admin sessions end after 60 minutes idle and 12 hours in all, are bound to the browser, and their ID is rotated during use. |
| Rate limits | Every sign-in, password reset, public form and write route is throttled (the member sign-in at 8 a minute, password reset at 5). |
| Bots | Optional Cloudflare Turnstile on the join, contact, sign-in and password forms; tokens are verified with Cloudflare and must have been solved on the site's own hostname. |
| Authorisation | Staff get admin areas, each at view, edit or manage, plus named rights (such as "see money" or "send campaigns"). Every admin screen and action checks them; settings pages are for full administrators only. Every member route checks ownership or visibility. A staffer can only manage accounts whose rights they could grant themselves. |
| Members' privacy | Each member chooses, field by field, who sees their details: all members, their own year group, or nobody. Email and phone start hidden. |
| Input and output | CSRF protection on every form (the few exemptions are signed or HMAC-verified). Output is escaped; rich text is cleaned to an allow-list. CSV exports neutralise spreadsheet formulas. SQL sorting and filtering columns are allow-listed. |
| Content-Security-Policy | One policy per page, built from the site's settings: a third-party host is allowed only when an integration that needs it is switched on, and only on the pages that need it. Every page has its own nonce; no inline script runs without it, anywhere. The public site and member area allow no eval, no inline style and images only from the site and the hosts a switched-on feature names. The admin panel keeps eval, inline styles and https images, which its framework (Filament 5) needs - see the remaining risks below. Check my headers (Settings > Security) shows what really reaches a browser. |
| Other headers | nosniff, X-Frame-Options and frame-ancestors, Referrer-Policy, Permissions-Policy, COOP/CORP; the PHP version header is removed. |
| Uploads | File types are decided from the content, not the name. Contact-form attachments, imports and association papers live on a private disk and are only handed out after an authorisation check. The public uploads folder ships with rules that switch PHP off and serve HTML and SVG as text (Apache; docs/server/nginx.conf has the Nginx equivalent, an untested sample). |
| Outgoing requests | Webhooks, push and feeds only go to public addresses: the address is checked in DNS, the connection pinned to it, and redirects are not followed. |
| Secrets | SMTP password, payment, SMS, WhatsApp, AI, social sign-in and map keys, the Turnstile secret and the backup passphrase are encrypted at rest with the site's own key (AES-256) and never sent back to the browser. API tokens are stored only as SHA-256 hashes. |
| Audit log | Sign-ins, failed sign-ins (email masked), changes to members, users, money, content and settings, downloads of private files and bulk changes, with who, when and from which IP. Kept 365 days. Changed field names are kept for every record; before-and-after values only for member and user profile fields, never for passwords or secrets. |
| Logs | One file a day, kept 14 days, warnings and errors only. Stack traces are written without function arguments, so a failed sign-in cannot leave a password in a log. |
| Backups | Optional nightly backups of the database and uploads to a private folder outside the website, with a weekly restore test. With a backup passphrase they are encrypted (AES-256, PBKDF2 with 600,000 rounds; readable with standard OpenSSL). Only full administrators can ask for a backup from the admin (one at a time, at most one every 10 minutes) or download one. Only encrypted backups can be downloaded, never a plain one: after typing the account password again (five wrong ones lock the step for 15 minutes), through a signed link that lasts two minutes and works for that account alone, with the backup chosen by an id and never by a file name. Each request and each download is in the audit log, and a download alerts the administrators. |
| Data protection | A member downloads everything held about them (staff notes included) from their account. Deletion requests have a deadline you set (30 days by default) and are carried out by anonymising the record, its audit trail included. Retention periods for rejected applications, contact messages and email tracking are set on Settings > Privacy & cookies. Tracking tags wait for consent, by category. |
| Accessibility | Aims for WCAG 2.2 AA on the public site and the member area - see Accessibility. |
What has been checked, and how
- Every release is tested in-house, and what was tested is published with the results: Security tests lists each tool with its version, date, scope and how much it checked (a dependency audit of
composer.lock, the bundled JavaScript against a vulnerability database, a code scan, a secret scan, a web scan of a local copy, the automated test suite) and every finding with its status: fixed (with its regression test), accepted or a false positive (with the reason), or open. - The code reviews were done by AI code reviewers (Claude), directed by Cerevonix: release 2.0.0 on 25 and 26 September 2026, and each later batch of changes. Their findings and fixes are in Security review and in Security tests.
- An automated test suite runs before every change is accepted; every security fix has a regression test. The count for this release is in Security tests.
- No external penetration test has been done. These are our own tests, not an independent audit.
Remaining risks we know of
Stated plainly, from the review:
- In the admin panel the Content-Security-Policy still allows
evaland inline styles, which its framework needs, so there it limits where scripts load from and which inline scripts run (only those with the page's nonce) but not what an injected Alpine expression could do. The public site and member area allow neither. - The eight low-severity items the reviews had left open are fixed in 2.0.0; what each fix does, and its test, is in the Security review, "The low findings closed in 2.0.0". What stays as it is by design: staff who cannot use their authenticator app can still ask for an emailed code (the account is now told by email when one is used), and a site that is also reached on a second subdomain must list it in
TRUSTED_HOSTS. The list of every finding is in Security tests, "Every finding". - Being self-hosted, the security of the server, PHP version, database, TLS certificate, backups of the whole account and the operating system is the host's and yours.
Part 2 - Answers in the style of a HECVAT Lite
Shortened question wording. "Yes" means the software does it as described; "Host" means it depends on where you install AlumDeck.
Company and documentation
| Question | Answer |
|---|---|
| Vendor name, address, contact for security matters | Cerevonix FZ-LLC, United Arab Emirates (licensed by RAKEZ, Ras Al Khaimah). Security questions and reports go through the contact form at https://alumdeck.com/contact/ (topic "Security report"); we reply to a security report within 2 working days. Support goes through the same form, with a reply target of one working day, Monday to Friday. |
| Is the product hosted by the vendor (SaaS)? | No. It is installed on the institution's own hosting. The vendor operates only the licence server. |
| Do you have a SOC 2, ISO 27001 or similar certification? | No. Cerevonix holds no SOC 2, ISO 27001 or other certification. |
| Do you have cyber insurance? | No. Cerevonix holds no cyber insurance policy at present. |
| Is there documentation for installing and securing the product? | Yes: docs/01 to docs/11, shipped with every download and readable inside the admin (System > Help). |
| Is there a published accessibility statement? | Yes, a template for your own site in Accessibility; the product aims for WCAG 2.2 AA. |
Application security
| Question | Answer |
|---|---|
| Is the application tested for security before release? | Yes, in-house, and the results are published in Security tests: a dependency audit, code and secret scans, a web scan of a local copy, the automated test suite, and code reviews by AI code reviewers (Claude) directed by Cerevonix. No external penetration test. |
| Has a third party penetration-tested it? | No. |
| Are known vulnerabilities in third-party libraries tracked? | The PHP dependencies are fixed by composer.lock and updated with each release. Before every release composer audit checks every locked package, and the bundled JavaScript libraries are checked against the OSV database (Security tests). Between releases there is no fixed schedule: the same checks run again when a release is prepared and whenever a security report arrives. |
| Do you protect against the OWASP Top 10? | Yes, as listed in Part 1: authorisation on every route, CSRF, output escaping and HTML cleaning, parameterised queries with allow-listed sorting, SSRF guards, secure headers, rate limits, encrypted secrets. |
| Is there a Content-Security-Policy? | Yes, built from settings, with a new nonce on every page; no inline script without it. The public site allows no eval or inline style; the admin panel allows both (see remaining risks). |
| Can the institution change or review the source? | No. AlumDeck's PHP code ships encoded (ionCube); the page templates, translations, these guides and the third-party libraries in vendor/ are plain. The licence does not allow the encoded code to be modified or decoded. |
Authentication and authorisation
| Question | Answer |
|---|---|
| Does the product support single sign-on? | Yes, for members: SAML 2.0, OpenID Connect and CAS, plus Google, Microsoft, LinkedIn, Facebook and Apple. Staff may link a provider to their own account and still pass their second sign-in step. |
| Is multi-factor authentication available for administrators? | Yes, and required for all staff: authenticator app (TOTP) or emailed code. |
| Password policy | At least 12 characters; bcrypt hashing; throttled attempts. |
| Role-based access | Yes: admin areas with view, edit or manage levels, and named rights. |
| Session timeouts | Admin: 60 minutes idle, 12 hours absolute. Member sessions: 120 minutes idle by default (SESSION_LIFETIME). |
| Are privileged actions logged? | Yes, in the audit log (365 days). |
Data
| Question | Answer |
|---|---|
| What personal data does the product store? | What your association enters or members provide: names, contact details, year group, profile, membership and event records, gifts and payments (amounts; card data never reaches AlumDeck - payments are handled on the provider's own pages), messages and forum posts. You decide which modules and profile fields are used. |
| Where is the data stored? | In your database and upload folders, on your hosting. For your IT to fill in: the data centre's location. |
| Does the vendor have access to institutional data? | No. Only if you give us access for support, under Part 3. |
| Is data encrypted in transit? | Yes, over HTTPS (Host: the TLS certificate). |
| Is data encrypted at rest? | Secrets and sessions are encrypted by AlumDeck. Encryption of the database and disks is the host's. Backups are encrypted when a backup passphrase is set. |
| Can data be exported? | Yes: CSV exports in the admin, a member's own full data export, and the REST API. |
| Can data be deleted? | Yes: deletion requests anonymise a member's record and audit trail; retention periods remove old applications, contact messages and email tracking. |
| Is data used for analytics or AI training by the vendor? | No. No data reaches the vendor. |
Hosting, continuity and change
| Question | Answer |
|---|---|
| Data centre, physical security, firewalls, intrusion detection | Host. For your IT to fill in. |
| Backups | Your host's account backups, and optionally AlumDeck's own nightly backups with a weekly restore test, encrypted with a passphrase. |
| Disaster recovery | Restore the database and upload folders on any server that meets the requirements (docs/01, docs/03). |
| How are updates delivered? | A new release is announced by email, with the download link, while the licence is current. An administrator applies it, from the Updates screen in the admin or by hand from the zip (docs/03). Nothing updates by itself. |
| What happens if the licence lapses or the vendor disappears? | The public site keeps running. After a 21-day grace period signing in pauses until renewal. A site needs a signed answer from the licence server at least every 60 days: if the licence server stopped answering, signing in would pause 81 days after the last answer, with a warning banner for the last 21. If Cerevonix ever stops trading, we will publish a final release of AlumDeck that runs without the licence check. No escrow arrangement is offered. |
| What does the licence check send and receive? | It sends the licence key, the site's host name and a one-time random number (the optional update check adds the version). It receives an answer signed with the vendor's Ed25519 key, which the site verifies with PHP's sodium extension. One licence covers one site (its host name). No member data travels either way. |
Incident handling and privacy
| Question | Answer |
|---|---|
| How do you notify customers of a security issue in the product? | By email to licence holders, with the fixed release, and in an advisory published with the fix (listed in Security tests). A Critical or High problem is fixed within 30 days of the report. |
| Who handles a breach of the institution's own server? | The institution and its host; AlumDeck's audit log, sign-in records and IP addresses help the investigation. |
| Does the product support GDPR rights? | Yes: access (self-service export), rectification (profile and admin editing), erasure (anonymisation), retention periods, consent by cookie category, and an audit trail. |
Part 3 - Data processing agreement (template)
Because AlumDeck is self-hosted, the vendor does not process your members' personal data in normal use. This template covers the cases where it might: when you give the vendor access for support (an admin account, a copy of the database, log files or screenshots). Have it checked by your own adviser; it is a starting point, not legal advice.
Data Processing Agreement
Between [Institution] ("the Controller") and Cerevonix FZ-LLC, United Arab Emirates (licensed by RAKEZ, Ras Al Khaimah) ("the Processor"), for the AlumDeck software licence dated [date].
- Subject. The Processor processes personal data only when the Controller gives it access to an AlumDeck installation or to data from one, to provide support the Controller asked for. The software itself runs on the Controller's infrastructure, and in normal use no personal data of the Controller's members reaches the Processor. The licence check sends only a licence key and a site address, which are not personal data of members.
- Data and people. The personal data the Controller chooses to share for the support request: typically members' and staff names, contact details, membership, event and giving records held in AlumDeck. Special-category data only if the Controller has stored and shared it.
- Instructions. The Processor acts only on the Controller's documented instructions (the support request), and does nothing else with the data.
- Confidentiality. Everyone at the Processor who sees the data is bound to confidentiality.
- Security. The Processor uses access given to it only for the request, from secured devices; keeps any copy encrypted; and deletes copies and asks for access to be withdrawn when the request is closed, within [14] days.
- Sub-processors. The Processor uses no sub-processor for the Controller's personal data without the Controller's prior written consent. For support correspondence the Processor uses its web host, which serves alumdeck.com and carries the email its contact form sends; it uses no other sub-processor for the Controller's personal data.
- Transfers. Data is not transferred outside [region] unless the Controller agrees and appropriate safeguards are in place.
- Assistance. The Processor helps the Controller answer data-subject requests and meet its obligations on security, breach notification and impact assessments, as far as the support access allows.
- Breaches. The Processor tells the Controller without undue delay, and within [48] hours, after becoming aware of a personal-data breach involving the Controller's data, with what it knows.
- Deletion. At the end of a support request, and at the end of the licence, the Processor deletes the Controller's personal data it holds and confirms this in writing.
- Audit. The Processor makes available the information needed to show it meets this agreement, and allows reasonable audits at the Controller's cost.
- Law. This agreement is governed by the law of [jurisdiction].
Signed for the Controller: ____________________ Date: __________
Signed for the Processor: ____________________ Date: __________
Back to the README (README.md)
Guide 10 of 10
Keep reading
The ten guides ship together in the zip, in this order.
Stuck on something this guide does not cover?
Write to the people who build AlumDeck through the contact form. We aim to reply within one working day, Monday to Friday: a target, not a guarantee.