Scope and Objectives

This policy applies to all Mentu services, its infrastructure, personnel, and contractors. It covers all processes that manage, store, or transfer information.
The measures defined herein aim to protect both explicit and implicit information during its transfer, use, and storage, under the principles of confidentiality, integrity, and accountability (CIA).

Definitions

• Educational Information: Data related to students/teachers associated with the use of Mentu services.

• Compliance: Alignment of processes and policies with applicable regulations and recommended best practices.

• Information: A critical asset in any format (digital, physical, verbal) that requires protection.

• Databases: Any information storage system containing user or service data from Mentu, including but not limited to cloud-based platforms.

• Cloud Infrastructure Platforms: Any service or group of services provided to Mentu in SaaS, PaaS, or IaaS format.

• Confidentiality: Ensuring information is accessible only to authorized individuals or systems.

• Integrity: Maintaining accuracy and completeness of information, preventing unauthorized modifications.

• Availability: Ensuring that information and systems are accessible when needed.

• Accountability: Keeping a record of user actions and ensuring user awareness of those actions.

• Awareness: The baseline knowledge and risk sensitivity of users regarding their actions and the necessary security measures.

• Information Asset: Any resource (data, software, hardware, personnel) that holds value for the organization.

• Threat: An event or action that may cause harm to assets (e.g., malware, phishing, natural disasters).

• Vulnerability: A weakness in a system or process that can be exploited by a threat.

• Risk: The likelihood that a threat will exploit a vulnerability and cause negative impact.

• Security Control: Technical, administrative, or physical measures to mitigate risks (e.g., firewalls, access policies).

• Security Incident: An event that compromises the confidentiality, integrity, or availability of information.

Principles

• CIA Triad: Foundation of information security—confidentiality, integrity, and availability.

• Risk Management: Proactively identifying, assessing, and addressing risks.

• Least Privilege: Granting only the necessary access to perform specific functions, based on Role-Based Access Control (RBAC).

• Defense in Depth: Implementing multiple layers of security (physical, logical, administrative) to ensure protection even if one control fails.

• Legal and Regulatory Compliance: Adhering to laws, regulations, and contracts related to data protection.

• Awareness and Training: Educating employees, partners, and third parties on security best practices.

• Incident Response: Establishing protocols for detecting, containing, and recovering from incidents.

• Continuous Improvement: Reviewing and updating policies in response to technological, organizational, or regulatory changes.

• Information Lifecycle: Managing data from creation to secure disposal, including backups and encryption.

Asset Protection and Classification

Information is categorized to ensure proper handling:

• Public: Freely distributable, non-identifiable data (e.g., institutional announcements).

• Internal: Restricted to organizational use, may include grouped or identifiable data.

• Confidential: Sensitive information with restricted access (e.g., educational or private data).

• Restricted: Highly sensitive data whose disclosure may cause significant harm (e.g., minors' data, medical records).

All services must indicate the criticality level of their information if disclosing the information security policy is required.
Unclassified information assets should be treated as confidential.

Asset Protection and Classification

Information assets may be spread across different platforms or physical locations. Therefore, mapping and classification are necessary for adequate protection.
An up-to-date inventory must be maintained with at least the identifier, classification, and location. It can be supplemented with an access inventory.

Access and Permissions Policy

Applies to all services used by employees, contractors, and users.

Users accessing sensitive data or critical services with elevated privileges must use multi-factor authentication. Credential rotation and use of robust mechanisms are recommended.

Infrequently used critical services should enforce strong credentials and multi-factor authentication.

Institutional accounts must be used instead of personal ones for associating processes or services.
Authentication/authorization systems should use service accounts, not personal ones.

Credential requirements:

• Minimum secure length (currently 8–10 characters).

• Alphanumeric combinations with special characters (&^%$!@*-).

• Use robust password managers.

• Rotate credentials at least every six months.

• Avoid reusing credentials across services.

• Do not include personal data in credentials.

• Avoid using MFA on the same device.

• Never store credentials in plain text or on sticky notes.

Access must be limited to what is strictly necessary.
Credentials are personal and must not be shared.
Access must be revoked upon employee offboarding.

Clean Desk Policy: Do not leave confidential or restricted information unattended. Avoid sticky notes with credentials or leaving sessions open.

Enable session auto-lock or sign-out after inactivity, and ensure log-out at day’s end or after browser closure.

Digital Information Systems Protection Policy

Encryption and Tokenization

Sensitive data must be encrypted in transit and at rest using strong algorithms.
Tokenization should be used when processing in less secure environments.
Use mirrored or read-only systems for data handling.

Access Management

Access is role-based, ensuring minimal necessary privileges.
MFA and audit logs should be implemented incrementally across services.

Hardening and Infrastructure Security

Secure configurations for servers, databases, and apps.
Regular vulnerability assessments to manage critical risks promptly.
Track vulnerabilities and train staff to avoid introducing new ones.
Implement secure development practices and design products with security in mind.
Isolate development and production environments—separate keys, networks, permissions.
Avoid public exposure of critical services, even if authentication exists.
Schedule regular infrastructure maintenance and updates.

Monitoring and Logging

Log detailed interactions and critical operations for audit and forensic purposes.
Use SIEM tools to detect incidents early.
Allow staff to report incidents and suggestions.

Transparency in Communication

Clearly communicate policy updates via training and internal publications.
Keep OS and application software up to date.
Use antivirus and cybersecurity best practices. Follow BYOD policy, use VPN, and separate work/personal sessions.
Prefer cloud workspaces and avoid saving sensitive data on personal devices.

Security Incident Management Policy

Cybersecurity incidents must be carefully handled and logged.
Incidents arise from threats analyzed in risk assessments with corresponding controls. Controls may include Playbooks for various threats.

Incident Severity Levels

• Level 1 (Low): Minimal impact, no compromise of information.

• Level 2 (Medium): Moderate impact requiring intervention to avoid escalation.

• Level 3 (High): Significant impact, potential compromise of critical information or business continuity.

• Level 4 (Critical): Severe disruption, loss of sensitive data, or full company-wide security breach.

Criteria to Evaluate and Classify an Incident

• Operational Impact: Business continuity and service availability.

• Scope: Systems, data, and users affected.

• Confidentiality: Exposure of sensitive data.

• Integrity: Unauthorized data manipulation.

• Urgency and Response Time: Speed required to contain and recover.

Incident Management Procedure

Alerts can come from monitoring systems or manual scans.
Alerts must be evaluated by qualified personnel.

• Conduct a preliminary analysis to assign provisional severity and designate an incident commander.

• Execute a response plan, maintain a war room, follow threat-specific playbooks, and adhere to communication protocols.

• Apply mitigation measures and activate business continuity mechanisms.

• Monitor post-incident to ensure resolution.

• Document actions, decisions, and results for audits and process improvement.

Throughout the process, communication must follow the incident communication plan. The incident commander or their delegate is the main point of contact for clients.

Business Continuity and Disaster Recovery Policy

The continuity plan must prioritize the most critical processes.

• Identify essential processes/services and assess their disruption impact—considering CIA principles, financial, reputational, and legal implications.

• Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each process/system.

• Implement redundant systems or rapid deployment of affected services.

• Perform regular backups of critical data to secure locations (cloud/offsite).

• Consider data replication across data centers.

• Define frequency, methods, and responsibilities for backups, and test them periodically.

• List priority systems/applications for recovery.

• Document recovery procedures: reinstallation, configuration, and verification.

• Define recovery order based on impact and dependencies.

• Establish agreements with critical vendors for timely support and replacement.

• Maintain updated contact details and communication protocols.

• Create a communication plan for internal/external use, to be activated only for graded incidents.

• Assign a response team authorized to activate and coordinate recovery.

• Document lessons learned and maintain systematic records for audits.

• Define and create Post-Mortem reports for drills and real incidents.