Trust
Security overview
We sell a cybersecurity product, so it would be a poor look to describe our own security in marketing language. This page states what is implemented, in specific terms, and then states plainly what is not.
Derived from the application source. Every statement below describes code that exists in the product today.
Implemented controls
Tenant isolation
Every scoped record carries an organisation id, and access resolves through a single chokepoint rather than a filter applied per query. An MSP can reach the client organisations on its plan and nothing else. Cross-tenant attempts are refused and logged.
Access control
Two dimensions, both required. Plan-level feature flags decide what an organisation has bought; role-based permissions decide who inside that organisation may use it. A technician cannot reach billing or branding, or record a decision on a client’s behalf.
Password storage
bcrypt at cost 12. A constant-time comparison is performed even when no account exists, so a missing account cannot be identified by response timing.
Password policy
Twelve character minimum with mixed case and a digit, checked against a common-password list. Length is weighted over symbol complexity — the same advice the training gives.
Sessions
An HS256 JWT in an httpOnly, secure, sameSite=lax cookie, pointing at a database row carrying an expiry and a revocation timestamp. A password reset or an administrator deactivation revokes every session immediately.
Brute force and enumeration
Per-IP and per-account rate limits with a fifteen minute account lockout after eight failures. Login and password reset return identical responses whether or not the account exists.
Rate limiting
Database-backed fixed-window buckets on login, signup, password reset, contact, exports, decisions and quiz submission — so limits survive serverless cold starts rather than resetting with the process.
CSRF
Server Actions carry the framework origin check, with an explicit double-submit token at the form boundary in addition.
Input and output handling
Every server action validates with a schema, and enum values are checked against allow-lists rather than cast from user input. The markdown renderer is tokenised and never emits raw HTML, so authored content cannot inject script.
Audit and export logging
Every consequential action is logged with the actor, organisation, IP address and user agent. Exports are logged separately, because “what left the platform” is a different question from “what happened in it”.
Assessment and quiz integrity
Quizzes are graded server-side and correct answers are never sent to the browser before submission.
Immutability
Risk acceptance records are never edited. A correction creates a new version and preserves the original, because the value of the record is that it cannot be tidied up afterwards.
HTTP headers
Content Security Policy, HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a Referrer-Policy and a Permissions-Policy are sent on every response.
Search engine exposure
Every authenticated route sends X-Robots-Tag: noindex, nofollow and is disallowed in robots.txt. Headers are the enforcement; robots.txt is the request.
Secrets
No customer passwords, API keys or credentials for third-party systems are stored in the schema. Password reset tokens are stored hashed; the raw value exists only in the emailed link.
Simulation safety
Phishing templates are scanned server-side on the launch path. Templates requesting card details, bank details, tax file numbers, identity document numbers or cryptocurrency keys are blocked, as are prohibited scenario themes. The sending provider is chosen by environment configuration and never by a tenant.
Not yet implemented
These are deliberate scope boundaries rather than oversights, and they are listed here for the same reason we list them internally — a security page that only contains good news is not a security page.
Multi-factor authentication on Cyber Guys accounts
Not yetThe schema columns exist and the architecture is ready, but the enrolment and challenge interface is not built. Accounts are currently protected by password, rate limiting and lockout only.
Enforced email verification
Not yetA verification timestamp exists and is set when an invitation is accepted, but self-signup does not currently require verification before use.
Direct file upload
Not yetBranding logos are supplied as URLs rather than uploaded, which avoids upload handling entirely. Object storage with content-type validation would be needed to change that.
Independent security certification
Not yetCyber Guys holds no ISO 27001, SOC 2 or equivalent certification. We are not going to imply otherwise on a page about security. If a certification becomes relevant to our customers, we will pursue it and say so here with the certificate details.
A published data-location statement
Not yetWe are not making a data sovereignty or hosting-location claim until the production region is fixed and independently verifiable. See below.
Hosting and data location
Cyber Guys runs on a managed Node host with a managed PostgreSQL database. We are not publishing a hosting provider, a region or a data sovereignty claim until that configuration is fixed for production and can be verified by a customer who asks.
Production hosting region and data location statement — to be confirmed
If data location matters to your procurement or regulatory position — and for many Australian organisations it does — please raise it with us directly before you buy, rather than relying on an inference from this page.
Subprocessors
These are the categories of external service the platform depends on. Where a provider is not yet named, it is because the production configuration is not settled — the application supports several options for each, and naming the supported options would tell you nothing about what actually processes your data.
- Application hosting — Runs the web application. A standard Node application, deployable to Vercel or any Node host. Provider — to be confirmed
- Database hosting — Stores all customer records. PostgreSQL, deployable to any managed Postgres provider. Provider — to be confirmed
- Transactional email — Sends invitations, password resets and training assignment notices. With no provider configured, messages are written to the server log rather than sent. Provider — to be confirmed
- Phishing simulation email — Sends simulated phishing messages. Deliberately a separate provider and sending domain from transactional email, so a simulation can never originate from the address that sends password resets. Provider — to be confirmed
The full table, alongside business identity and hosting, is on the trust centre.
Content protection
Some of what follows is a commercial control rather than a security control, but it affects what can leave the platform, so it belongs on this page.
- Substantive content requires an authenticated and paid account.
- Training modules, explainers and objections are never publicly indexable.
- There are no editable document exports. PDF only, and only as the output of completed work.
- There is no bulk export endpoint and no template-extraction route.
- Every export is logged with the user, organisation, resource and timestamp.
- Demo organisations receive watermarked PDFs, enforced at the serving layer.
- Secure share links carry an expiry and a view cap.
Reporting a vulnerability
If you believe you have found a security issue in Cyber Guys, we want to hear about it and we will not take action against you for reporting it in good faith.
Doing security due diligence on us?
Ask for whatever you need. If we cannot answer something, we would rather tell you that than send a filled-in questionnaire that overstates the position.