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 GRC Eye 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.
• Account protection — account lockout after repeated failed sign-ins and a configurable password policy.
• Role-based access control — 13 built-in roles determine which modules and records an account can reach. A user can hold several roles, and team groups make assignment easier.
• 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.
• Active Directory / LDAP sign-in — organisations that centralise identity can let users sign in with their directory account, with AD groups mapped to GRC Eye roles.

Tenant isolation

GRC Eye 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. The log is tamper-evident: entries are hash-chained so the trail can be independently verified. This is both a security control and a compliance feature: most of the frameworks GRC Eye supports require an audit trail of changes to the control environment.

Uploaded evidence and contracts carry file integrity checks and a version history, so you can show which version of a document was reviewed and that it has not been altered since.

Private AI on your terms

GRC Eye's AI features — gap analysis, contract review, document generation, vendor prescreening — are advisory: people make the final decisions. Where the AI runs is your choice:

• Private edition — run GRC Eye on-premises or air-gapped with a local model. Your control evidence, contracts and draft policies never leave your network: zero data egress.
• Bring your own AI model — connect your own Ollama or OpenAI-compatible endpoint, so AI processing runs where you decide.

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

GRC Eye can be run as a managed SaaS deployment or, with the Private edition, installed on-premises in your own environment — as Docker containers, a VMware OVA appliance or an offline installer for air-gapped networks, with offline licence keys. On-premises 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 GRC Eye, 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.