Security isn't a feature.
It's the foundation.
You trust us with a decade of your students' marks, your staff's salaries, and your college's finances. Here's exactly how we protect it.
How we defend your data.
Isolated databases
Every college gets its own MySQL database — not a shared table. A bug in another tenant's code can never expose your data.
End-to-end encryption
TLS 1.2+ on every connection. AES-256 at rest. Integration secrets (Razorpay / SMS / WhatsApp keys) encrypted with per-deployment keys.
Role-based access
100+ granular permissions mapped to built-in + custom roles. Every sensitive action writes to an immutable audit log.
Automated backups
Daily mysqldump, gzipped, 30-day retention. Optional S3 / Google Drive offsite sync. One-command restore in under 15 minutes.
Incident response
24/7 on-call rotation. <72h breach notification commitment. Public status page at status.mcollege.in.
Infrastructure hardening
All traffic through AWS ALB + WAF. VPC-isolated database tier. Zero-trust SSH. MFA enforced for all staff.
Tenant isolation
We don't believe in “row-level” tenancy. Every college gets a physically separate MySQL database with its own connection pool, file storage directory, and cache namespace.
- Central database stores only billing, plan assignments, and tenant metadata.
- Each tenant database is provisioned on signup and destroyed on deletion.
- File uploads live in tenant-scoped directories — your logos, photos, certificates never share a bucket with another college's data.
- Query mis-routing between tenants is architecturally impossible — the tenant context is resolved from the subdomain at request-time.
Encryption
In transit: All traffic uses TLS 1.2+ with modern cipher suites. HTTP is redirected to HTTPS at the load balancer.
At rest: Amazon EBS volumes are encrypted with AES-256. S3 backups use server-side encryption with KMS-managed keys.
Application-layer: Integration secrets (Razorpay keys, SMTP passwords, WhatsApp tokens) are encrypted at the field level with Laravel's Crypt::encryptString before they're stored.
Authentication & access control
- Password storage: Bcrypt with cost factor 12. No plain-text passwords in logs, ever.
- Session security: HTTP-only, Secure, SameSite=Lax cookies. Sessions rotate on login.
- RBAC: 100+ granular permissions like
fees.concession,students.delete,reports.view. Each role maps to a permission set. - Audit log: Every mutation (edit, delete, payment, role change) logs actor / target / timestamp / diff, stored in an append-only table.
- Staff access: M College employees can only access tenant data with explicit permission or in response to a support ticket you opened. All access is logged and reviewed.
- MFA (optional): TOTP-based 2FA available for owner and admin roles.
Backups & recovery
- Automated
mysqldumpof every tenant database nightly at 02:00 IST. - Dumps are gzipped and stored in tenant-scoped folders under
storage/app/backups/. - 30-day rolling retention; older dumps auto-prune.
- Optional S3 / Google Drive sync — configurable per deployment.
- RTO: 15 minutes for a single tenant restore.
- RPO: 24 hours (last nightly dump).
- Self-service export: any tenant owner can download a full SQL dump from the admin console.
Monitoring & logging
- Application errors routed to a Sentry instance (scrubbed of PII).
- Structured logs shipped to a central log store with 90-day retention.
- Uptime monitored externally from 4 regions every 60 seconds.
- Anomaly alerts (failed-login spikes, unusual data-export patterns) trigger PagerDuty rotation.
Payments & PCI
We integrate with Razorpay for online fee collection. We never store card numbers or CVVs — Razorpay handles the PCI scope entirely. We only store order IDs, signatures, and receipt numbers for reconciliation.
Signature verification uses HMAC-SHA256 with constant-time comparison (hash_equals) to prevent timing attacks. Orders are idempotent — duplicate verification attempts return the same result without side effects.
Vulnerability management
- Dependency scanning: Composer & npm advisories checked daily via GitHub Dependabot.
- Static analysis: PHPStan level 6, Psalm type checks in CI.
- Secret scanning: every commit scanned for API keys / credentials before merge.
- Pen-testing: Annual third-party penetration tests. Summary report available under NDA.
- Bug bounty: responsible-disclosure program (see below).
Incident response
- Detection — alert triggers page primary on-call.
- Triage — severity classified within 15 minutes. SEV-1 issues escalate immediately.
- Containment — affected components isolated; kill-switch available for compromised tenants.
- Eradication & recovery — root cause fixed; affected tenants restored from last clean backup if necessary.
- Post-mortem — blameless review published internally within 72 hours.
- Notification — if personal data is confirmed breached, affected tenants notified within 72 hours per DPDP Act; public post-mortem within 14 days for SEV-1.
Compliance & certifications
- Data residency in India (AWS Mumbai region).
- DPDP Act 2023 aligned; DPO appointed.
- Aadhaar handling follows UIDAI's AUA/KUA norms (where applicable).
- ISO 27001 certification — in progress (target: Q4 2026).
- SOC 2 Type II — in progress (target: 2027).
Report a vulnerability
Found a security bug? Thank you — please tell us.
Email security@mcollege.in with:
- Steps to reproduce (screenshots / logs if helpful)
- Potential impact
- Your PGP key if you want encrypted correspondence
We acknowledge within 24 hours, triage within 72 hours, and publicly credit (with your consent) after a fix ships.
No public disclosure until we've had a reasonable window to fix (typically 90 days).
Last reviewed: April 22, 2026. For the most current security posture, see our annual transparency report at /legal/transparency.
Questions about security?
We're happy to walk you through our posture, provide pen-test summaries under NDA, or sign your vendor assessment.
security@mcollege.in