Loading page…
SecureGRC · security & trust
SecureGRC stores your risks, findings, evidence and unremediated gaps. That makes its own security model a legitimate part of your evaluation, so this page sets out what is implemented — by control domain, in the terms a security reviewer would use.
01 · Control domain
How a session is established, how long it lasts, and what stops a token being accepted where it should not be.
Authentication uses JWT bearer tokens. Issuer, audience and signature are all validated on every request — not merely decoded — so a token minted elsewhere or altered in transit is rejected rather than trusted.
The application refuses to start if the token signing secret is shorter than the enforced minimum. A weak key cannot be introduced by configuration error, because the service will not come up.
Access token lifetime is configuration-driven with a short default, and refresh tokens are issued at login. Session duration is a deployment decision rather than an application constant.
The platform provides directory and single sign-on configuration so authentication can be delegated to your existing identity provider, along with a SCIM endpoint for identity lifecycle integration.
Platform-level administration is served by a distinct application and a separate token issuance path, so tenant users and platform operators are not authenticated through the same surface.
03 · Control domain
In a multi-tenant platform this is the control that matters most, and the one most worth asking a direct question about.
A company claim is required for tenanted users and is carried in the access token itself, so tenant identity is established by the authentication layer rather than inferred from a request parameter.
Tenant isolation middleware validates the claim on the request path. Isolation is not left to individual query authors remembering to apply a filter.
Scoping is applied again where data access is constructed, giving a second independent enforcement point for the same property.
The platform administration console provides tenant backup, export, offboarding and purge workflows, so tenant data has a defined end-of-life rather than persisting by default.
04 · Control domain
The controls that reduce the blast radius of a web application vulnerability, and what the application discloses when something goes wrong.
Content Security Policy enforced in production, Strict-Transport-Security outside development, X-Content-Type-Options, X-Frame-Options, a restrictive Permissions-Policy and a strict referrer policy.
Traffic is served over HTTPS through the reverse proxy, with HSTS instructing browsers to refuse an unencrypted connection.
A global exception handler sanitises responses in production, so stack traces, framework internals and query detail are not returned to a caller.
A fixed-window rate limiter operates alongside a global limiter, providing a defence against automated abuse and credential attacks at the transport layer.
Cross-origin access is restricted to an allowlist that differs by environment, rather than a permissive policy carried from development into production.
Uploads are size-limited and stored through a provider abstraction — local, S3, S3-compatible, Google Cloud Storage or OCI. Documents are served through permission-checked preview endpoints rather than as raw storage URLs, so a leaked link does not become a leaked document.
Realtime notifications are delivered over an authenticated channel that carries the same user context as the rest of the application.
05 · Control domain
Whether the platform can answer, after the fact, who did what — which is the question your own auditors will put to it.
Administrative and record-level activity is captured in audit logs available within the product, so entitlement and configuration changes are reviewable rather than invisible.
Logging is structured with traceability across a request, so an investigation can follow an action through the layers that handled it.
Access review decisions retain a point-in-time snapshot of the access as it stood when reviewed. Certifying against current state rather than reviewed state is a common weakness elsewhere; here the reviewed state is what is recorded.
Copilot sessions, proposed actions, approvals and executions are held as audit entities, so an AI-assisted change carries the same trail as a manual one.
06 · Control domain
AI in a GRC platform touches the records your assurance depends on. The governing question is what it can do without a person.
AI proposes; a person with the appropriate permission approves and executes. There is no configuration in which AI alters your GRC records without human approval, and the approval is recorded.
Three provider models are supported: application-managed, your own provider key, or a private self-hosted model. Where data residency or model exposure is a constraint, the self-hosted route keeps inference inside your boundary.
Prompt safety controls and sensitive-data filters are applied to AI interactions rather than passing content through unexamined.
AI retrieval operates within the requesting user's authorisation, so the assistant cannot surface records the user could not otherwise reach.
Suggested control mappings carry a stated rationale and confidence, and the mapping snapshot is retained — so an AI-assisted decision remains auditable after the fact.
07 · Control domain
The properties that determine whether the platform can be operated reliably by whoever is responsible for running it.
API, tenant application, administration console and reverse proxy are built and deployed as separate images, so components are released and rolled back independently.
Liveness, readiness and general health endpoints are exposed for orchestration and monitoring, so failure is detected by the platform rather than reported by a user.
Application metrics are published via OpenTelemetry in Prometheus format, so the platform integrates with the monitoring you already operate.
A defined pipeline runs validation, backend test execution, image build and deployment, so releases follow a repeatable path rather than a manual one.
Recurrence, reminders and escalation run as managed background jobs, so scheduled governance activity does not depend on someone being logged in.
Enterprise due diligence
Some of what a security review needs is specific to your deployment, and some of it should not be published on a public page. We handle those requests directly, under NDA where appropriate.
We complete standard and bespoke security questionnaires as part of an evaluation, and will state plainly where the answer is that a control is not implemented.
Hosting arrangement, data residency, environment separation and network architecture, discussed against your specific requirements rather than a generic description.
Processing terms, sub-processor position, retention and deletion arrangements, and the tenant offboarding and purge process.
Backup arrangements and recovery expectations for your deployment model, agreed as commitments rather than described in the abstract.
How vulnerability reports are received, triaged and remediated, and how customers are informed where relevant.
The SecureGRC technical whitepaper covers architecture, data model, security controls and operational design in depth, and is available to organisations under evaluation.
Responsible disclosure
If you believe you have found a vulnerability in SecureGRC or in this website, we want to hear about it.
Write to info@dabstergroup.com with “Security disclosure” in the subject line, and enough detail to reproduce the issue.
Security questions
Including the ones where the answer is that it depends on your deployment.
Evaluation
We complete standard and bespoke questionnaires as part of an evaluation, and we will state plainly where a control is not implemented rather than answering around it.