This page states how the platform handles credentials, sessions, audit records and your data. It describes what is implemented today rather than an aspiration, because a security page is the first thing a competent reviewer tests.
Passwords are hashed with scrypt from the Node standard library, with a unique salt for every account and a constant-time comparison on verification.
The cost parameters are stored inside each hash rather than in configuration, so parameters can be raised over time without invalidating existing credentials. A stored hash records the settings it was created with, and an older hash remains verifiable after the defaults move.
The session cookie is HTTP-only, scoped with SameSite set to lax, and marked secure in production so it is never transmitted over plain HTTP.
HTTP-only means client-side JavaScript cannot read the cookie, so a cross-site scripting flaw cannot exfiltrate a session. Each user record carries a session version, which allows every existing session for an account to be invalidated at once when a credential changes or an account is locked.
Audit entries are written as a hash chain. Each record carries a sequence number and the hash of the record before it, so the log detects tampering rather than merely recording events.
The chain can be recomputed on demand and will report the first record that does not verify. This matters because an audit log that can be edited quietly is evidence of nothing. Records are written as work happens rather than reconstructed afterwards.
Acceptance of the Terms, Privacy Policy, Acceptable Use Policy and Data Processing Agreement is recorded against the document version that was accepted, the person who accepted it, and the time.
Because acceptance is versioned, a later change to a document does not silently rewrite what a customer agreed to. Where an agreement binds the organisation rather than the individual, the record states that, and only a person authorised to sign for the organisation may accept it.
The application and its database are hosted in Frankfurt, in the European Union.
Our sub-processor register names every third party with access to customer data, and states the purpose of each. If your regulator requires domestic residency for a specific dataset, raise it during scoping, because that is a design question rather than a paperwork question.
Access by our staff is limited to what support requires, and it is recorded in the same audit chain as everything else.
Roles inside your organisation are yours to assign. An organisation owner controls who in their company can see what, and every access decision is visible to you as well as to us.
Assessment results, control mappings, evidence records and reports are exportable in open formats, and you may request deletion of your organisation's data.
The Data Processing Agreement sets out the deletion process and the retention periods that apply where a record must be kept for a legal reason. Leaving should cost you effort, not your history.
SecureEdge Advisory does not hold an independent security certification of its own platform at this time. The controls above are described because they are implemented, not because a third party has attested to them. When we complete a certification, this page will say which one, who issued it, and when it expires. We apply the same standard to ourselves that we apply on your behalf: an internal statement is a statement, and only an external auditor affirms.
If you believe you have found a security issue in this platform, report it to us directly and we will acknowledge it. We would rather hear it from you than read about it later.