Contents
- 1. Introduction
- 1.1 Purpose
- 1.2 Scope
- 1.3 Security Principles
- 2. Security Governance
- 2.1 Security Programme
- 2.2 Governance Objectives
- 2.3 Shared Responsibility
- 3. Security Architecture
- 3.1 Defence in Depth
- 3.2 Security by Design
- 3.3 Privacy by Design
- 4. Identity and Access Management
- 4.1 Role-Based Access Control
- 4.2 Principle of Least Privilege
- 4.3 Authentication
- 4.4 Session Security
- 5. Encryption and Data Protection
- 5.1 Encryption in Transit
- 5.2 Encryption at Rest
- 5.3 Password Protection
- 5.4 Cryptographic Management
- 6. Tenant Isolation
- 6.1 Multi-Tenant Architecture
- 6.2 Access Validation
- 6.3 Administrative Separation
- 7. Infrastructure Security
- 7.1 Cloud Infrastructure
- 7.2 Network Protection
- 7.3 Secure Deployment
- 8. Secure Software Development
- 8.1 Secure Development Lifecycle
- 8.2 Change Management
- 8.3 Vulnerability Management
- 9. Security Monitoring and Audit Logging
- 9.1 Security Monitoring
- 9.2 Audit Logging
- 9.3 Log Protection
- 9.4 Monitoring Limitations
- 10. Backup and Disaster Recovery
- 10.1 Backup Strategy
- 10.2 Protected Backups
- 10.3 Disaster Recovery
- 10.4 Testing
- 11. Security Incident Response
- 11.1 Incident Management
- 11.2 Incident Response Process
- 11.3 Customer Notification
- 11.4 Incident Reporting
- 12. Business Continuity
- 12.1 Operational Resilience
- 12.2 Availability Planning
- 12.3 Continuous Service Improvement
- 13. Third-Party Risk Management
- 13.1 Third-Party Services
- 13.2 Risk Assessment
- 13.3 Ongoing Review
- 14. Security Responsibilities of Schools and Users
- 14.1 School Responsibilities
- 14.2 User Responsibilities
- 14.3 Mobile Device Security
- 15. Responsible Security Disclosure
- 15.1 Reporting Security Concerns
- 15.2 Responsible Disclosure Expectations
- 16. Continuous Improvement
- 16.1 Security Evolution
- 16.2 Policy Review
- 16.3 Relationship with Other Trust Centre Documents
1. Introduction
1.1 Purpose
Aionpixel Technologies Private Limited ("Aionpixel", "we", "our", or "us") is committed to protecting the confidentiality, integrity, availability, and resilience of information processed through Cortex IOS.
Cortex IOS is a cloud-based School Operating System that processes information relating to educational institutions, including students, parents and guardians, teachers, School staff, School management, and authorised users.
This Information Security Statement provides a high-level overview of the administrative, technical, and organisational measures that support the security of Cortex IOS.
This document is intended to provide transparency regarding our security approach. It does not disclose confidential security configurations, implementation details, or operational procedures that could reduce the effectiveness of our security controls.
1.2 Scope
This Statement applies to the Cortex IOS ecosystem, including:
- public websites
- Trust Centre
- web portals
- Android applications
- iOS applications
- APIs
- cloud infrastructure
- communication services
- integrations
- operational support systems
- supporting technology operated by Aionpixel for Cortex IOS
1.3 Security Principles
The Cortex IOS security programme is guided by the following principles:
- Security by Design
- Privacy by Design
- Defence in Depth
- Least Privilege
- Role-Based Access Control
- Tenant Isolation
- Secure Development Practices
- Continuous Improvement
- Accountability
- Operational Resilience
- Security controls are reviewed and enhanced as Cortex IOS evolves
2. Security Governance
2.1 Security Programme
Information security is incorporated into the design, development, deployment, operation, and maintenance of Cortex IOS.
The security programme seeks to protect:
- customer information
- student records
- School operations
- platform availability
- authentication systems
- communications
- financial information processed through authorised workflows
- supporting infrastructure
2.2 Governance Objectives
Our security programme seeks to:
- protect confidentiality
- preserve integrity
- maintain availability
- support resilience
- minimise operational risk
- support legal compliance
- support contractual commitments
- continually improve security maturity
2.3 Shared Responsibility
Security is a shared responsibility between:
Aionpixel
Responsible for:
- operating Cortex IOS
- infrastructure security
- platform security
- software maintenance
- secure development
- operational monitoring
- backup management
- incident response
- technical support
- security governance
Schools
Responsible for:
- assigning authorised users
- reviewing permissions
- protecting School-managed devices
- maintaining user governance
- defining School security policies
- ensuring appropriate use of Cortex IOS
Users
Responsible for:
- protecting credentials
- maintaining device security
- using authorised accounts only
- reporting suspicious activity
- complying with School policies
3. Security Architecture
3.1 Defence in Depth
Cortex IOS applies multiple layers of security controls rather than relying upon a single control.
These layers may include:
- authentication
- access control
- encryption
- application security
- infrastructure security
- network protection
- monitoring
- logging
- backups
- operational controls
- incident response
3.2 Security by Design
Security considerations are incorporated throughout the software lifecycle.
Examples include:
- secure authentication
- secure APIs
- secure communications
- role-based permissions
- audit capability
- tenant separation
- encrypted storage
- secure deployment practices
- dependency management
- change management
3.3 Privacy by Design
Security controls are designed to support privacy obligations.
Examples include:
- minimising unnecessary access
- limiting privileged access
- supporting consent records
- supporting auditability
- protecting sensitive information
- separating tenant information
- secure handling of authentication information
4. Identity and Access Management
4.1 Role-Based Access Control
Access to Cortex IOS is based upon authorised roles.
Examples include:
- School Management
- Principal
- Administrator
- Teacher
- Parent
- Student
- Accountant
- HR Personnel
- Support Personnel
- other authorised School-defined roles
Users receive access only to the functions required for their responsibilities.
4.2 Principle of Least Privilege
Users should receive the minimum access necessary to perform their authorised duties.
Permissions should be reviewed periodically by the School.
Access should be removed promptly when no longer required.
4.3 Authentication
Cortex IOS supports secure authentication mechanisms appropriate to the platform.
Authentication controls may include:
- secure passwords
- session management
- authentication tokens
- secure credential handling
- password reset workflows
- account lockout protections where applicable
- additional authentication measures supported by the deployment
4.4 Session Security
Authenticated sessions may include controls supporting:
- secure session identifiers
- inactivity management
- session expiry
- token validation
- secure logout
- protection against session misuse
5. Encryption and Data Protection
5.1 Encryption in Transit
Information transmitted between supported Cortex IOS clients and platform services is intended to use modern encrypted communication protocols.
Encryption in transit helps protect information against unauthorised interception during transmission.
5.2 Encryption at Rest
Where implemented within the Cortex IOS architecture, information stored within supported cloud infrastructure is protected using encryption technologies appropriate to the platform and service.
Encryption methods may evolve over time as technology and security practices improve.
5.3 Password Protection
Passwords are not intended to be stored in plain text.
Authentication information is handled using secure authentication practices appropriate to the platform architecture.
5.4 Cryptographic Management
Cryptographic controls may include:
- key management
- certificate management
- secure protocol selection
- encrypted communications
- periodic review of cryptographic technologies
Specific cryptographic implementations are not publicly disclosed for security reasons.
6. Tenant Isolation
6.1 Multi-Tenant Architecture
Cortex IOS is designed as a multi-tenant SaaS platform.
Logical separation mechanisms are intended to prevent one School from accessing another School's information.
6.2 Access Validation
Every authenticated request is evaluated according to applicable:
- tenant
- School
- user role
- permissions
- relationships
- authorised modules
- platform controls
6.3 Administrative Separation
Administrative capabilities are also governed by role-based controls.
Administrative users are not automatically authorised to access information belonging to another tenant.
Privileged operational access is controlled according to authorised responsibilities.
7. Infrastructure Security
7.1 Cloud Infrastructure
Cortex IOS operates using professionally managed cloud infrastructure selected to support:
- security
- availability
- resilience
- scalability
- operational continuity
- disaster recovery
Infrastructure providers may implement physical, environmental, and operational security controls appropriate to cloud-hosted services.
7.2 Network Protection
Security controls may include:
- secure network segmentation
- firewalls
- network monitoring
- traffic filtering
- intrusion detection or prevention capabilities where implemented
- denial-of-service mitigation measures appropriate to the deployment
7.3 Secure Deployment
Software deployments are managed through controlled operational processes intended to reduce deployment risk.
Changes are subject to testing and operational review before production deployment where appropriate.
8. Secure Software Development
8.1 Secure Development Lifecycle
Security is considered throughout the software development lifecycle.
Development activities may include:
- secure coding practices
- peer review
- dependency review
- vulnerability assessment
- functional testing
- regression testing
- security testing where appropriate
- controlled release management
8.2 Change Management
Changes to Cortex IOS are managed through structured development and deployment processes.
The objective is to minimise operational disruption while maintaining security and reliability.
8.3 Vulnerability Management
Aionpixel seeks to identify, assess, prioritise, and remediate security vulnerabilities affecting Cortex IOS.
The prioritisation of remediation activities depends upon:
- severity
- exploitability
- operational impact
- customer risk
- platform architecture
Public disclosure of vulnerabilities is coordinated through responsible security practices.
9. Security Monitoring and Audit Logging
9.1 Security Monitoring
Aionpixel operates monitoring processes intended to support the ongoing security, reliability, and operational health of Cortex IOS.
Monitoring activities are designed to assist in:
- detecting unauthorised access
- identifying suspicious activity
- monitoring platform availability
- identifying operational anomalies
- detecting potential misuse
- supporting incident response
- maintaining service reliability
Monitoring activities are conducted in accordance with applicable legal requirements and operational necessity.
9.2 Audit Logging
Cortex IOS is designed to maintain audit records for significant platform activities where appropriate.
Depending upon the module and functionality, audit records may include:
- user authentication events
- account creation
- account modification
- password reset events
- role assignment changes
- administrative actions
- configuration changes
- workflow approvals
- assessment publication
- financial transaction events
- communication activities
- security events
- other significant operational activities
Audit logging supports accountability and assists with troubleshooting, compliance, and security investigations.
9.3 Log Protection
Security and audit logs are treated as operational security information.
Access to such logs is restricted to authorised personnel with an operational need.
Logs are protected against unauthorised alteration using appropriate technical and operational controls.
9.4 Monitoring Limitations
Although Cortex IOS incorporates monitoring capabilities, no monitoring programme can guarantee the detection or prevention of every security event.
Security monitoring forms one component of a broader defence-in-depth strategy.
10. Backup and Disaster Recovery
10.1 Backup Strategy
Aionpixel maintains backup processes intended to support:
- business continuity
- disaster recovery
- accidental data loss recovery
- operational resilience
- restoration of authorised services where necessary
Backups are maintained using secure operational procedures appropriate to the Cortex IOS environment.
10.2 Protected Backups
Backup copies are intended to be protected using appropriate administrative, technical, and organisational safeguards.
These safeguards may include:
- controlled access
- encryption where implemented
- secure storage
- operational monitoring
- lifecycle management
Backups are not intended to function as ordinary user-accessible archives.
10.3 Disaster Recovery
Disaster recovery planning seeks to minimise disruption following significant operational events.
Recovery activities may include:
- restoration of critical services
- infrastructure recovery
- application recovery
- database recovery
- integrity verification
- security validation
- controlled return to normal operations
Recovery priorities may depend upon the nature of the incident and operational requirements.
10.4 Testing
Where appropriate, recovery processes may be reviewed or tested periodically to support operational preparedness.
Testing activities may evolve as Cortex IOS grows and operational maturity increases.
11. Security Incident Response
11.1 Incident Management
Aionpixel maintains processes intended to support the identification, assessment, containment, investigation, remediation, and review of information security incidents.
Security incidents are prioritised according to factors such as:
- severity
- operational impact
- information affected
- customer impact
- regulatory considerations
- platform availability
11.2 Incident Response Process
The general incident response lifecycle includes:
- Identification
- Assessment
- Containment
- Investigation
- Remediation
- Recovery
- Post-Incident Review
Operational procedures supporting these activities are maintained internally.
11.3 Customer Notification
Where a confirmed security incident materially affects customer information or services, Aionpixel will assess notification obligations in accordance with:
- applicable law
- contractual commitments
- the nature of the incident
- regulatory requirements
- the role of the affected School
Notifications may be provided directly to the authorised School representatives.
11.4 Incident Reporting
Users and Schools are encouraged to promptly report suspected:
- unauthorised access
- credential compromise
- suspicious communications
- suspected malware
- privacy incidents
- technical vulnerabilities
- fraudulent activity
- other security concerns
Reports should be made through authorised School channels or directly to Aionpixel where appropriate.
12. Business Continuity
12.1 Operational Resilience
Aionpixel seeks to maintain operational resilience through:
- cloud infrastructure
- backup processes
- redundancy where appropriate
- operational monitoring
- controlled deployment practices
- incident response
- disaster recovery planning
- continual operational improvement
12.2 Availability Planning
Business continuity planning seeks to minimise disruption resulting from:
- infrastructure failures
- communication failures
- software defects
- operational incidents
- cyber security events
- cloud service interruptions
- other unforeseen operational events
12.3 Continuous Service Improvement
Business continuity arrangements are reviewed and refined as Cortex IOS evolves.
Operational improvements may be introduced to strengthen platform resilience and customer experience.
13. Third-Party Risk Management
13.1 Third-Party Services
Cortex IOS relies upon selected third-party service providers to support authorised platform functionality.
Examples include providers supporting:
- cloud infrastructure
- communication services
- payment processing
- authentication
- monitoring
- diagnostics
- analytics
- AI-assisted functionality where enabled
- other supporting technical services
13.2 Risk Assessment
When selecting third-party providers, Aionpixel seeks to consider:
- security capability
- operational maturity
- service reliability
- privacy practices
- contractual protections
- business continuity
- regulatory considerations
- technical suitability
The level of assessment may vary according to the service being provided.
13.3 Ongoing Review
Third-party relationships may be reviewed periodically to ensure continued suitability.
Service providers may change over time as Cortex IOS evolves.
Updated information regarding material provider categories may be published through the Cortex IOS Trust Centre.
14. Security Responsibilities of Schools and Users
14.1 School Responsibilities
Schools should:
- manage authorised users
- periodically review permissions
- promptly remove unnecessary access
- maintain accurate user information
- protect administrative credentials
- establish internal security policies
- educate users regarding responsible platform use
- promptly report suspected security incidents
14.2 User Responsibilities
Every authorised user should:
- maintain password confidentiality
- use only authorised accounts
- protect devices used to access Cortex IOS
- promptly install application updates
- avoid sharing authentication credentials
- report suspicious activity
- review AI-generated content before use where applicable
- comply with School policies and these Platform Terms
14.3 Mobile Device Security
Users accessing Cortex IOS through mobile devices should:
- enable device authentication where available
- keep operating systems updated
- avoid installing untrusted applications
- protect notification privacy where appropriate
- report lost or stolen devices promptly
- sign out where continued access is no longer authorised
15. Responsible Security Disclosure
15.1 Reporting Security Concerns
Security researchers, Schools, customers, and authorised users are encouraged to report suspected security vulnerabilities responsibly.
Reports may include:
- authentication weaknesses
- authorisation issues
- security configuration concerns
- suspected vulnerabilities
- unexpected security behaviour
- other legitimate security observations
15.2 Responsible Disclosure Expectations
Individuals reporting potential vulnerabilities should:
- act in good faith
- avoid disrupting production services
- avoid accessing information belonging to others
- avoid exploiting vulnerabilities beyond what is reasonably necessary to demonstrate the issue
- provide sufficient information to reproduce the concern
- allow Aionpixel reasonable opportunity to investigate before public disclosure
Nothing in this Statement authorises unauthorised testing, scanning, penetration testing, or attempts to compromise Cortex IOS without prior written approval.
16. Continuous Improvement
16.1 Security Evolution
Information security is an ongoing process.
Aionpixel continually reviews opportunities to strengthen Cortex IOS through:
- platform improvements
- architectural enhancements
- updated technologies
- improved monitoring
- improved operational procedures
- enhanced authentication
- improved encryption practices
- vulnerability remediation
- customer feedback
- evolving industry practices
16.2 Policy Review
This Information Security Statement will be reviewed:
- annually
- following significant platform changes
- following material changes to security practices
- following major regulatory developments
- where otherwise considered appropriate
16.3 Relationship with Other Trust Centre Documents
This Statement should be read together with:
- Cortex IOS Product Privacy Policy
- Cortex IOS Data Governance Statement
- Cortex IOS Platform Terms of Service
- Cortex IOS Cookie & Similar Technologies Policy
- Cortex IOS Parent & Guardian Privacy Notice
- Cortex IOS Student Privacy Notice
- Cortex IOS School Staff Privacy Notice
- Cortex IOS Legal & Transparency Statement
Annexure A - High-Level Security Architecture
- Authorised User
- Authentication
- Role & Tenant Validation
- Encrypted Communication
- Application Services
- Authorised Data Processing
- Encrypted Storage
- Protected Backup
- Monitoring & Audit Logging
This diagram illustrates the high-level security architecture adopted by Cortex IOS. It is intentionally simplified and does not disclose confidential implementation details.
Annexure B - Public Security Control Matrix
| Security Domain | High-Level Controls |
|---|---|
| Identity Management | Authenticated user accounts, role-based access control |
| Authentication | Secure authentication, session management, credential protection |
| Access Control | Least privilege, role assignment, tenant isolation |
| Encryption | Encryption in transit, encryption at rest where implemented |
| Network Security | Secure communication, network protection, traffic controls |
| Application Security | Secure development practices, controlled deployment, vulnerability management |
| Infrastructure Security | Cloud infrastructure, operational monitoring, resilience |
| Monitoring | Audit logging, security monitoring, operational monitoring |
| Backup & Recovery | Protected backups, disaster recovery planning |
| Incident Response | Identification, containment, investigation, recovery |
| Third-Party Risk | Provider assessment, contractual safeguards |
| Governance | Policy review, accountability, continuous improvement |
Annexure C - Version History
| Version | Date | Description |
|---|---|---|
| 1.0 | 29th June 2026 | Initial Information Security Statement |
| 2.0 | 16th July 2026 | Comprehensive revision aligned with Cortex IOS Trust Centre, Product Privacy Policy, Data Governance Statement, Platform Terms of Service, web portal, Android and iOS applications, multi-tenant SaaS architecture, AI-assisted functionality, and enterprise security transparency. |