Security at Pathshala

Pathshala OS runs entirely on Amazon Web Services in the United States. All traffic is encrypted in transit and all durable storage is encrypted at rest. Authentication is handled by Amazon Cognito with strong password hashing, email verification, and optional MFA. Per-Institute data isolation is enforced at the database and storage layer. Privileged production access is granted on a least-privilege basis, and every admin action is recorded in a tamper-evident audit log. We back up the database daily and S3 buckets are versioned; the recovery plan is exercised periodically. A published vulnerability-disclosure policy invites researchers to report findings; documented incident-response procedures define how we triage and notify.

• Cloud provider. AWS, US regions (primary us-east-1, secondary us-east-2).
• Compute. AWS Lambda + managed runtimes; no long-lived application VMs we have to patch.
• Database. Amazon DynamoDB and (where relational) Amazon RDS, both with encryption-at-rest enabled.
• Object storage. Amazon S3, versioning enabled on Customer Content buckets.
• CDN. Amazon CloudFront with AWS WAF managed rules + Cloudflare in front for institute custom domains and bot mitigation.
• DNS. Amazon Route 53.
• Region disclosure. Personal data is processed and stored in the United States. International transfers are handled under EU SCCs / UK IDTA where required (see the DPA).

• In transit. TLS 1.2 or higher; HTTP automatically redirects to HTTPS; HSTS with a 2-year max-age, includeSubDomains, and preload eligible.
• At rest. AES-256 with AWS-managed keys for DynamoDB, S3, RDS, EBS, and Cognito.
• Database backups. Encrypted with the same KMS key as the source database.
• Secrets. Stored in AWS Secrets Manager / Parameter Store, never in source code.

• Identity store: Amazon Cognito.
• Password storage: bcrypt-style adaptive hashing (Cognito-managed).
• Email verification required on signup.
• MFA: opt-in for admins; required for Pathshala employees with production access.
• Rate limiting on login, signup, and password-reset endpoints (AWS WAF rate-based rules + per-IP Lambda quotas).
• Sessions: short-lived access tokens, refresh tokens with rotation, HttpOnly/Secure/SameSite cookies.
• Password reset uses single-use, time-bound tokens delivered out-of-band by Amazon SES.

Every API endpoint validates three things on every request: authentication, role permission, and tenancy ownership. Roles include Super Admin (Pathshala), Institute Owner, Institute Admin, Tutor, Student, Parent, Support Staff. Default policy is deny; permissions are granted explicitly.

Pathshala OS is multi-tenant. Each Institute has its own tenant identifier that is included in every database key, every S3 prefix, and every API authorisation check. There is no shared row in any Institute-scoped table. Pathshala super-admin queries are paginated and audit-logged.

• Application logs. Centralised in Amazon CloudWatch with retention configured per log group.
• Audit logs. All admin actions, role changes, exports, and deletions are recorded in a separate, append-only audit-log table.
• Threat detection. Amazon GuardDuty for account and workload anomaly detection.
• WAF logs. AWS WAF logs forwarded to CloudWatch and reviewed periodically.
• Alarms. Latency, error-rate, and unusual-activity alarms page on-call.

• Daily point-in-time recovery snapshots of DynamoDB tables.
• S3 versioning + lifecycle rules on Customer Content buckets.
• Recovery procedures documented; restore drills run periodically.
• Recovery Point Objective (RPO): 24 hours. Recovery Time Objective (RTO): 8 hours for critical systems.

• Mandatory peer review on every change; protected main branches.
• Automated dependency-vulnerability scanning (GitHub Dependabot).
• Automated static analysis on each pull request; lint + type-check gates merges.
• Secrets scanning on each commit.
• Pre-production environment (staging) used for QA before any change reaches production.
• Infrastructure-as-code (AWS CDK); manual production changes are forbidden.

• Every employee and contractor signs a confidentiality agreement.
• Production access is granted least-privilege and is time-bound where possible.
• Annual security and privacy training; ad-hoc training when laws change materially.
• Onboarding includes a security briefing; offboarding revokes access within one business day.

Our incident-response process follows the standard NIST SP 800-61 stages:

1. Detect via alarms, customer reports, or researcher submissions.
2. Triage and contain within minutes for high-severity events.
3. Investigate the scope and root cause.
4. Notify affected institutes and authorities (where required) without undue delay, within 72 hours for personal-data breaches under GDPR / DPDP / state laws.
5. Recover with verified restorations.
6. Document and learn — every P0/P1 incident produces a written post-mortem; preventive actions are tracked to completion.

Report a security incident: security@pathshala.co.

The authoritative list of every third-party service we rely on is at /legal/subprocessors. We give Institute owners 30 days' notice before adding or replacing a sub-processor.

• Today. Operational alignment with COPPA, FERPA, GDPR, UK GDPR, DPDP Act 2023, CCPA / CPRA. Pre-signed DPA and FERPA addendum. Strict opt-in cookie consent.
• Next. External penetration test once user-volume justifies the spend.
• Then. SOC 2 Type II attestation for the Service.
• Long-term. ISO/IEC 27001 once SOC 2 is renewed for a second year.

We follow the priority order in our public DPA and avoid premature spending on certifications that don't yet match Pathshala's stage; trust is earned by the operational practices on this page, not by certificate stickers.