Core Security Controls & Mechanisms
Verified security mechanisms implemented across our application stack.
Ballot Secrecy & Token Decoupling
Voter identity records are architecturally separated from stored resolution choices. Under Rule 20(4)(xii), individual voter selections cannot be viewed by the company or third parties prior to official unblocking by the Scrutinizer.
SHA-256 Merkle Audit Proofs
Every cast ballot produces an immutable SHA-256 hash mathematically linked into a hierarchical Merkle Tree. If any ballot record in the session is modified, the resulting Merkle root alters, providing verifiable tamper evidence.
2FA OTP Authentication
Time-limited one-time passwords (OTP) sent directly to registered email and phone contacts protect user sessions. Client-side SHA-256 hashing and server-side rate limits prevent credential stuffing and brute-force attacks.
PostgreSQL Row-Level Security (RLS)
Database records are guarded by strict PostgreSQL RLS policies. Companies can only access data belonging to their own meetings, and shareholders can only access resolutions tied to their registered folio entitlement.
Security & Compliance Trust Matrix
A transparent comparison between legal frameworks, platform technical controls, and certification status.
| Category | Regulatory Standard | Platform Implementation | Status |
|---|---|---|---|
| Voter Authentication | Rule 20(4)(iv) | 2FA OTP verification via email & SMS | Implemented |
| Ballot Secrecy | Rule 20(4)(xii) | Decoupled voter tokens & sealed tally vault | Implemented |
| Audit Trail Integrity | Rule 20(4)(xv) | SHA-256 Merkle Tree mathematical ledger | Implemented |
| Scrutinizer Export | Form MGT-13 | Automated PDF audit report generation | Implemented |
| Agency Accreditation | Depository / STQC | Independent software demonstration | Not Certified |
Security Frequently Asked Questions
Detailed answers on our cryptographic protocols, access controls, and data privacy.