Skip to main content

Security Policy

Effective Date: 30 March 2026

Platform: Campus 24x7 - School ERP Software

1. Purpose

This Security Policy defines the technical and organizational safeguards implemented to ensure:

  • Confidentiality of institutional and student data
  • Integrity of academic and financial records
  • Availability and reliability of services

2. Scope

Applies to:

  • All users (institutions, staff, students, parents)
  • All systems (frontend, backend, database, infrastructure)
  • All data processed within the platform

3. Infrastructure Security

3.1 Hosting Environment

  • Hosted on Hostinger VPS
  • Isolated production, staging, and development environments
  • Controlled administrative access with least-privilege enforcement

3.2 Server Hardening

  • SSH access via key-based authentication only
  • Root access restricted
  • Firewall (UFW/Nginx rules) configured
  • Unused ports and services disabled

3.3 Network Security

  • Reverse proxy via Nginx
  • Rate limiting and request throttling enabled
  • HTTPS enforced (TLS 1.2+)
  • Protection against brute-force and common network attacks

4. Application Security

4.1 Secure Development Lifecycle

  • Backend: NestJS (modular architecture, validation pipelines)
  • Frontend: React (TypeScript) with strict typing
  • Code reviews and structured deployment process

4.2 Authentication

  • Secure login with bcrypt password hashing
  • Multi-Factor Authentication (MFA) enabled for privileged roles
  • Token-based authentication (JWT)
  • Session expiration and token invalidation

4.3 Authorization

  • Fine-grained Role-Based Access Control (RBAC)
  • Permissions configurable per institution
  • Enforcement at API and service layers

4.4 API Security

  • All endpoints authenticated and authorized
  • Input validation and sanitization
  • Protection against SQL Injection, XSS, and CSRF

5. Data Security

5.1 Data Classification

  • Highly Sensitive: Student personal data, financial records
  • Sensitive: Academic and operational data
  • Non-sensitive: Public information

5.2 Data Storage

  • Stored in MySQL database
  • Tenant isolation enforced via institution-scoped queries
  • Strict query validation middleware

5.3 Encryption

  • Data in transit encrypted (HTTPS)
  • Sensitive fields encrypted where applicable
  • Passwords hashed (bcrypt)

5.4 Backup and Recovery

  • Automated periodic backups
  • Secure storage of backups
  • Regular restoration testing

6. Multi-Tenant Security

  • Logical tenant isolation enforced at application layer
  • All queries scoped by institution ID
  • Middleware-level validation prevents cross-tenant access
  • Regular validation checks for isolation integrity

7. Access Control and Audit

7.1 Internal Access Control

  • Access limited to authorized personnel only
  • Role-based internal access enforcement

7.2 Audit Logging

Comprehensive logging of:

  • Login activity
  • Data creation and modification
  • Permission changes

7.3 Exportable Audit Logs

  • Institutions can access and export audit logs
  • Supports transparency and compliance requirements

8. Monitoring and Logging

  • Centralized managed logging system
  • Real-time monitoring of errors, suspicious activities, and performance anomalies
  • Alerts configured for critical events

9. Incident Response

In case of a security incident:

  1. Detection and validation
  2. Immediate containment
  3. Root cause analysis
  4. Vulnerability remediation
  5. Notification to affected institutions (if required)
  6. Post-incident review and improvement

10. Vulnerability Management

  • Regular dependency updates (Node.js, NestJS, libraries)
  • Security patches applied promptly
  • Periodic vulnerability assessments

11. Third-Party Security

Third-party services include:

  • Hosting provider (Hostinger VPS)
  • Payment gateways
  • Communication providers (SMS and email)
  • Meta Platforms (WhatsApp Business Cloud API) - for transactional WhatsApp notification delivery

Controls:

  • Minimal data sharing
  • Vendor reliability and security evaluation
  • All API integrations use encrypted channels (TLS 1.2+)
  • Third-party API credentials are stored securely and not exposed externally

12. Data Breach Policy

In case of a confirmed breach:

  • Immediate containment and investigation
  • Impact assessment
  • Notification to affected institutions within reasonable time
  • Implementation of corrective measures

13. Compliance

Aligned with:

  • Information Technology Act, 2000 (India)
  • SPDI Rules, 2011 (Reasonable Security Practices)
  • Industry-standard SaaS security practices

Future alignment:

  • ISO 27001 (planned)
  • GDPR (if applicable)

14. Business Continuity and Disaster Recovery

  • Backup-driven recovery strategy
  • RPO: less than or equal to 24 hours
  • RTO: 4 to 8 hours

15. User Responsibilities

Users must:

  • Maintain credential confidentiality
  • Enable MFA where applicable
  • Avoid credential sharing
  • Report suspicious activity immediately

16. Limitations

Security controls reduce risk but cannot eliminate:

  • Advanced persistent threats
  • Zero-day vulnerabilities
  • User negligence
  • Infrastructure-level failures

17. Policy Updates

  • Policy may be updated periodically
  • Continued platform use implies acceptance

18. Contact

For security concerns or vulnerability reporting:

Email: info@campus24x7.in

19. Meta WhatsApp Business API Security

19.1 Overview

Campus 24x7 integrates Meta's WhatsApp Business Cloud API as a Meta-approved Tech Provider to deliver transactional notifications on behalf of institutional clients. This section defines the specific security controls applied to this integration, in compliance with Meta's Developer Data Use Policy (Section 6.1) and Platform Terms.

19.2 API Credential Management

  • Meta API access tokens and app secrets are stored encrypted at rest using industry-standard encryption
  • Credentials are never stored in source code, version control systems, or client-facing configurations
  • Access to API credentials is restricted exclusively to authorized Campus 24x7 backend systems and personnel
  • API tokens are rotated periodically as a standard security practice
  • Upon any suspected credential compromise, tokens are invalidated and rotated immediately
  • Meta Business Manager account access is protected with two-factor authentication (2FA)

19.3 Webhook Security

  • Campus 24x7 uses HTTPS-secured webhook endpoints to receive delivery status callbacks from Meta's WhatsApp Cloud API
  • All incoming webhook requests are verified using Meta's webhook verification token before processing
  • Webhook endpoints are protected against replay attacks and unauthorized requests
  • Webhook payloads are validated and sanitized before being processed by backend systems
  • Webhook URLs are not publicly documented or exposed in client-facing systems

19.4 Data Minimization for API Calls

Only the minimum data required for message delivery is transmitted to Meta's API:

  • End-user phone number (E.164 format)
  • Approved message template name and variable values
  • Institution's WABA identifier
  • No student academic records, financial data, or sensitive personal data beyond the above is included in API payloads
  • API response data (delivery status, message ID) is stored only for operational support and audit purposes, for a maximum of 90 days

19.5 API Communication Security

  • All API requests to Meta's WhatsApp Business Cloud API are made exclusively over HTTPS (TLS 1.2+)
  • No API calls are made over unencrypted channels
  • API endpoints used are official Meta Cloud API endpoints only - no third-party proxies or intermediaries
  • API request and response logs are stored in the centralized logging system with restricted access

19.6 Meta-Specific Incident Response

In addition to the general incident response process (Section 9), the following steps apply specifically to incidents involving Meta API or WhatsApp data:

  1. Immediate revocation of compromised API credentials via Meta Business Manager
  2. Isolation of affected backend services
  3. Notification to affected institutions within 48 hours
  4. Reporting of the incident to Meta through the appropriate Meta developer reporting channel, in accordance with Meta's Platform Terms
  5. Root cause analysis and remediation
  6. Post-incident review and security hardening

19.7 WABA Isolation

  • Each institutional client's WhatsApp Business Account (WABA) is logically isolated within Campus 24x7's Tech Provider account
  • One institution's WABA cannot access or affect another institution's WABA
  • API calls are scoped strictly to the relevant institution's WABA identifier at all times

19.8 Compliance Alignment

WhatsApp API security controls are aligned with:

  • Meta Developer Data Use Policy (Section 6.1 - Data Security Requirements)
  • Meta Business Messaging Technology Provider Terms
  • Meta Platform Terms (effective February 3, 2025)
  • Information Technology Act, 2000 (India)
  • SPDI Rules, 2011