Security

Why this page exists

A governance, risk and compliance platform ends up holding the most sensitive summary of your organisation that exists anywhere: your gaps, your findings, your unremediated risks. That makes GRCEye itself a target, and makes our own security posture a fair question for any prospect to ask. This page answers it directly.

Authentication and access

• Multi-factor authentication — TOTP-based MFA is enforced as a real second step at login for enrolled accounts, not merely offered as an enrolment option.
• Role-based access control — every account carries a role (administrator, CISO, user, auditor) that determines which modules and records it can reach.
• Scoped auditor access — external auditors get a dedicated portal limited to the audits assigned to them and the documents attached to those audits. They never see the wider tenant.
• Single sign-on — SSO integration is available for organisations that centralise identity.

Tenant isolation

GRCEye is multi-tenant. Every record carries a tenant identifier, and every API endpoint resolves the caller's tenant from their authenticated session before it reads or writes anything. One customer's data is never reachable from another customer's session.

Audit trail

The platform records user actions — what was changed, by whom, and when — in an activity log available to tenant administrators. This is both a security control and a compliance feature: most of the frameworks GRCEye supports require an audit trail of changes to the control environment.

AI processing stays with you

This is the control that matters most for a GRC tool, and the one most competing platforms cannot offer. GRCEye's AI features — gap analysis, contract review, document generation, vendor prescreening — run on a locally hosted model rather than a third-party AI API.

Your control evidence, contracts and draft policies are not sent to an external model vendor. For an on-premise deployment, they never leave your network at all. If you have ever had a compliance tool fail its own vendor security review because it shipped your audit evidence to an external API, this is the difference.

Data protection

• Encryption in transit — all traffic to the platform is served over TLS.
• Credential handling — passwords are stored as salted hashes, never in recoverable form.
• Session management — authentication uses short-lived access tokens with separate refresh tokens.
• Data ownership — your content is yours. See the terms of service and privacy policy.

Deployment options

GRCEye can be run as a managed SaaS deployment or installed on-premise in your own environment. On-premise deployments give you full data residency: the application, the database and the AI model all run on infrastructure you control, with no egress to us.

Reporting a vulnerability

If you believe you have found a security issue in GRCEye, email security@grceye.com with enough detail to reproduce it. We will acknowledge your report, keep you updated while we investigate, and will not pursue action against researchers who report in good faith, act within the scope of their own test environment, and give us reasonable time to remediate before disclosure.

Please do not run automated scans or load tests against production without asking us first — contact us and we will arrange a window.

Security questionnaires

If you need a completed security questionnaire, a data processing agreement, or architecture detail for your vendor review, ask via the contact form and we will turn it around. Customers can also publish their own posture through the platform's built-in trust center.