Compliance data is among the most sensitive information an organisation holds. We've built
GRCfy Maestro with security as a first principle — not an afterthought. This page explains
exactly how we protect your data.
GRCfy Maestro is built for organisations that manage sensitive compliance programmes — audits, findings,
evidence, and regulatory submissions. The data your teams upload and generate is confidential, regulated,
and in many cases subject to the DPDP Act 2023, GDPR, or other data protection laws.
We treat that responsibility seriously. Security decisions at GRCfy Maestro are not delegated to a single
team — they are baked into architecture, code review, deployment processes, and how we hire and train
our engineers.
Privacy-by-design: Platform administrators (super_admin, app_admin) are structurally
excluded from accessing tenant audit data at the database query layer — not just the UI. Your
compliance data is never visible to GRCfy Maestro platform staff in normal operations.
Section 02
Infrastructure & Hosting
The platform is hosted on enterprise-grade cloud infrastructure with industry-standard physical security, redundant power, and network resilience.
All data is stored exclusively within India — platform databases on servers hosted by Squarebrothers Internet Services (Chennai), and evidence files and backups on Amazon Web Services S3 (ap-south-1, Mumbai).
Evidence files uploaded to the platform are stored in AWS S3 (ap-south-1, Mumbai, India), encrypted at rest using AES-256 (SSE-S3) with S3 Object Lock enabled. Daily database backups and log archives are stored in the same bucket and retained for 30 days.
Network-level firewalls restrict inbound traffic to necessary ports only. Production databases are not directly accessible from the internet.
Compliance logs are stored in a dedicated, isolated compliance database (separate from application data) to ensure log integrity even in the event of an application-layer compromise.
The application tier, database tier, and compliance logging tier run as separate processes with independent access controls.
Section 03
Encryption
In transit
All communication between your browser and the platform is encrypted using TLS 1.2 or higher. HTTP is automatically redirected to HTTPS.
HSTS (HTTP Strict Transport Security) headers prevent protocol downgrade attacks.
All database connections between the application and storage layer use encrypted channels.
At rest
User passwords are hashed with bcrypt (minimum cost factor 10). Plaintext passwords are never stored, logged, or transmitted — not even to GRCfy staff.
Sensitive configuration values — database credentials, SSO client secrets, SFTP passwords, SMTP credentials — are encrypted at rest using AES-256-CBC via Laravel's encryption layer. Plaintext values are never persisted to the database.
Evidence files stored on the platform's managed storage are covered by the underlying storage provider's at-rest encryption.
// Password hashing — bcrypt, never MD5 or SHA-1
algorithm: "bcrypt"// PHP password_hash() with PASSWORD_BCRYPT
cost_factor: 10// minimum; tuned upward as hardware improves
stored_form: "hash only"// plaintext discarded immediately after hashing
key_source: ".env APP_KEY"// never stored in the database
Section 04
Authentication & Access Control
Role-based access control
GRCfy Maestro implements a granular 11-role permission system. Every action — viewing audit data,
uploading evidence, updating control statuses, managing findings — is gated by explicit role checks
at the controller layer, not just the UI.
Tier
Roles
Audit data access
Platform
super_admin, app_admin, app_agent
None — by design
Audit firm — senior
audit_admin, lead_auditor
Own firm's audits only
Audit firm — reviewer
auditor, external_auditor, compliance_viewer
Assigned audits only
Client side
client_manager, client_admin, client_user
Own entity only
Password security
Platform administrators can enforce password complexity rules (minimum length, uppercase, numbers, special characters) and mandatory expiry periods for all users in their organisation.
Expired passwords trigger a forced change flow before the user can access any other part of the platform.
The platform records password_changed_at on every password update to enforce expiry accurately.
Single Sign-On (SSO)
SAML 2.0, OIDC, and LDAP/Active Directory integrations are supported. Organisations can enforce SSO so that all authentication flows through their own Identity Provider.
OIDC client secrets and LDAP bind passwords are encrypted at rest using AES-256-CBC before being stored. Plaintext values are not retained after initial configuration.
Just-in-time (JIT) provisioning creates accounts automatically on first SSO login, applying pre-configured role mappings from IdP group attributes.
IdP tokens are not persisted beyond the authenticated session.
Session security
Session tokens are regenerated on every login and invalidated on logout.
CSRF protection is enforced on all state-changing requests via a per-session XSRF token.
Session cookies use HttpOnly and Secure flags to prevent client-side script access and enforce HTTPS.
Section 05
Data Isolation
Compliance data belonging to different organisations must never be visible across tenants.
GRCfy Maestro enforces isolation at multiple layers:
Database-per-client architecture: Each client entity's audit data lives in a dedicated database, not a shared table with a tenant_id column. Cross-tenant queries are architecturally impossible at the SQL layer.
TenantContext resolution: Every request that accesses audit data resolves the correct tenant database connection from the authenticated user's context before any query is issued. Requests with an unresolvable context are rejected (404/403).
Self-hosted database option: Organisations that require physical isolation can configure GRCfy Maestro to store their audit data on their own database server (company-hosted or client-hosted mode). The application connects to their server for tenant data only — platform infrastructure never holds a copy.
Platform admin exclusion: Scope queries in every controller explicitly exclude platform administrator roles from accessing tenant audit data — this boundary exists in PHP query logic, not just middleware.
Section 06
Immutable Audit Trail
Every significant action on the platform — login, data access, record creation/update/deletion,
role change, permission grant, evidence review, force-delete — is written to an append-only
compliance log simultaneously in two places:
Immutability guarantee: Log records in the compliance database override save()
and delete() at the model layer — any attempt to modify or delete an existing log entry
throws a LogicException. Even platform administrators cannot alter log history through
the application.
Permanent deletion ("force delete") operations are logged separately in a recovery_logs
table with a mandatory, non-empty reason field, the actor's identity, and a cascaded record of
all dependent data that was removed. This log is also immutable and available for export as CSV.
Section 07
Evidence & File Security
Evidence files are served via authenticated, time-limited URLs — never exposed as publicly accessible static files.
Per-file upload size limits are enforced at the server layer (configurable per subscription plan, default 50 MB) to prevent abuse.
Storage quotas are enforced per subscription. Uploads beyond quota are rejected before any data is written to disk.
Evidence storage is configurable: local managed storage, Amazon S3, or customer-provided SFTP. All drivers are abstracted behind the same upload/retrieve/delete interface with consistent access controls regardless of driver.
XLSX file preview uses a server-side ZipArchive parser — no third-party JavaScript spreadsheet libraries with known CVEs (SheetJS was explicitly removed due to a high-severity vulnerability).
Cross-audit evidence flagging automatically notifies affected teams when evidence used across multiple audits is marked expired or incorrect, preventing stale evidence from quietly remaining in use.
Section 08
Application Security
GRCfy Maestro is built on Laravel 12 (PHP 8.2) with Inertia.js / React 19. Our standard defences against OWASP Top 10:
Threat
Control
SQL Injection
Laravel Eloquent ORM with parameterised queries throughout. Raw SQL only where necessary, always with bound parameters.
Cross-Site Scripting (XSS)
React's JSX automatically escapes all dynamic values. No dangerouslySetInnerHTML in production code paths.
CSRF
Laravel CSRF middleware enforced on all POST/PUT/PATCH/DELETE routes. Inertia.js sends the XSRF-TOKEN cookie automatically.
Broken Access Control
Role checks at the controller layer (not just middleware) for every action. abort_unless() / abort_if() guards on every sensitive method.
Security Misconfiguration
Debug mode disabled in production. Sensitive keys in environment variables, never in source code. Encrypted config values in DB.
Insecure Direct Object References
Route model binding resolves only records the authenticated user is scoped to. Tenant models are resolved after TenantContext is set — not via direct Laravel route model binding.
Third-party Component Risk
Dependencies monitored for CVEs. High-risk packages (e.g., SheetJS) replaced with first-party alternatives. Composer and npm lockfiles committed.
Section 09
Vulnerability Management
Composer (PHP) and npm (JS) dependencies are monitored for known CVEs. Critical and high-severity vulnerabilities are patched within 72 hours of disclosure.
All code changes undergo peer review before being merged to the main branch. Security-sensitive changes (auth, role checks, data access) require explicit review sign-off.
Periodic internal security reviews are conducted against the OWASP Top 10 and DPDP Act technical safeguard requirements.
External penetration testing is planned on an annual basis. Results and remediation timelines are tracked internally.
Section 10
Incident Response
We maintain an incident response plan covering detection, containment, eradication, recovery,
and post-incident review. In the event of a security incident affecting your data:
72-hour notification: We will notify affected customers without undue delay and within 72 hours of becoming aware of a personal data breach, as required by the DPDP Act and GDPR.
Scope & impact: Initial notification will include the nature of the incident, categories of data affected, approximate number of records, and immediate containment steps taken.
Ongoing updates: We will provide updates as the investigation progresses and will assist customers in fulfilling their own regulatory notification obligations.
Post-incident report: Following resolution, a summary report will be provided to affected customers covering root cause, timeline, and remediation actions.
To report a suspected security incident or data breach:
security@grcfy.com
Section 11
Business Continuity & Backups
Automated daily backups of the platform database. Backups are stored in an isolated location separate from the primary database.
Backup restoration procedures are tested periodically. Restoration time objectives are reviewed after each test.
Universal soft-delete on all core models (users, audits, entities, audit types) means accidental deletions can be recovered from the Recovery Vault before the retention window expires — without needing a full database restore.
Organisations using self-hosted (company-hosted or client-hosted) databases are responsible for their own backup and recovery procedures for tenant data stored on their infrastructure.
Section 12
Employee & Vendor Security
All GRCfy employees and contractors with access to production systems are subject to background verification, confidentiality agreements, and annual security training.
Production infrastructure access follows the principle of least privilege. Access is provisioned on a role and need basis and reviewed quarterly.
All production access requires multi-factor authentication (MFA). VPN or bastion host access is required for direct database connections.
Sub-processors (infrastructure hosting, AWS S3 object storage, email delivery, monitoring) are bound by data processing agreements and are evaluated for security posture before engagement. See the full sub-processor list.
Employee offboarding includes immediate revocation of all access credentials, SSH keys, and service accounts.
Section 13
Responsible Disclosure
We welcome security researchers who responsibly disclose vulnerabilities in GRCfy Maestro.
If you've discovered a potential security issue, please report it to us before public disclosure
so we can investigate and remediate it.
Scope — in scope for reporting:
Authentication or session management vulnerabilities
Cross-tenant data access or data isolation bypass
SQL injection, XSS, CSRF, or insecure direct object references
Privilege escalation or role bypass
Sensitive data exposure (e.g., credentials in logs, error responses)
Evidence file access control bypass
Out of scope:
Denial-of-service (DoS/DDoS) attacks
Social engineering or phishing of GRCfy employees
Vulnerabilities in third-party services outside our control
Issues requiring physical access to production infrastructure
Self-hosted customer database security (customer's own responsibility)
Our commitments to researchers:
We will acknowledge your report within 24 hours
We will provide an initial assessment within 5 business days
We will keep you updated on remediation progress
We will credit researchers (with your consent) in our security acknowledgements
We will not take legal action against researchers acting in good faith
AI-assisted evidence analysis is an optional feature available on AI-enabled subscription tiers.
The following controls govern how AI processing is secured and how personal data is protected
during AI operations.
Two-layer PII scrubbing pipeline
Evidence text is scrubbed of personal identifiers through two sequential stages before any data
leaves our infrastructure:
Layer 1 — Internal regex engine: An in-process PHP service replaces 11 categories of India-focused structured identifiers — email addresses, phone numbers, Aadhaar numbers, PAN numbers, credit/debit card numbers, IPv4/IPv6 addresses, Indian passport numbers, IFSC codes, dates of birth, and UPI VPAs — with redacted placeholders.
Layer 2 — AWS Bedrock Guardrail: Scrubbed text is passed through an AWS Bedrock Guardrail configured with NAME and ADDRESS PII entity filters only. No content filters, topic filters, or word filters are active — these are deliberately disabled to avoid false positives on compliance terminology. The Guardrail intercepts residual named entities that pattern-matching cannot detect.
No evidence files transmitted to AI
Original evidence files (PDFs, Word documents, spreadsheets) are never transmitted to the AI model.
Only extracted text — after both scrubbing stages — is included in the AI prompt. Image files and
scanned PDFs use AWS Textract (OCR) in ap-south-1 to produce text first; the original image is
not forwarded to the Claude model.
Data residency — India boundary
All AI inference uses AWS Bedrock in ap-south-1 (Mumbai, India). This applies to
both Standard (Claude Haiku 4.5) and Enterprise (Claude Sonnet 4.6) tiers. AWS Textract OCR also
runs in ap-south-1. Evidence text does not cross India's geographic boundary during AI processing.
Human-in-the-Loop — no autonomous AI writes
AI analysis is explicitly triggered by an auditor clicking "Run AI Analysis". The resulting
findings are displayed for human review and never automatically written to the audit record.
Auditors accept, modify, or reject AI output before it is committed. This design ensures that
AI is an advisory tool, not a decision-maker.
No model training on customer data
GRCfy Maestro accesses Claude models via the AWS Bedrock API under Anthropic's commercial service
terms. These terms explicitly prohibit Anthropic and Amazon from using customer-submitted prompts
or responses to train, retrain, or fine-tune AI models. Audit evidence submitted through the
platform is never used as AI training material.
No AI data persistence
Scrubbed evidence text sent to AWS Bedrock is processed in-request and not retained by AWS or
Anthropic after the API call completes. GRCfy Maestro does not store the scrubbed prompt in any
database, log file, or cache. The AI response (structured compliance findings) is stored against
the audit control record, but this contains no evidence text.
Audit trail for AI operations
Every AI analysis is written to the platform's immutable audit trail, recording: timestamp,
user ID, control reference, AI model tier used (Standard or Enterprise), and confidence score.
This trail supports accountability reviews and demonstrates Human-in-the-Loop compliance.