BrightCampus Security & Trust

Security Built Into Every Layer

Schools entrust BrightCampus with important information about students, families, teachers, staff and school operations.

We take that responsibility seriously.

BrightCampus is designed around a simple principle:

A user should only be able to access the information they are authorised to see.

Security is therefore considered across identity, permissions, school isolation, application design, infrastructure, data handling and operational processes.

1. School Data Isolation

BrightCampus is designed as a multi-school platform while maintaining clear institutional boundaries.

Private information belonging to one school must not be available to another school merely because both institutions use BrightCampus.

Access controls are designed to evaluate relevant institutional membership and authorisation before protected school information is returned.

2. Role-Based Access Control

Not everyone within a school requires the same level of access.

BrightCampus supports role-based permissions so that access can reflect a user's responsibilities.

Depending on school configuration, roles may include:

- School Owner; - School Administrator; - Principal; - Vice Principal; - Head of Department; - Academic Officer; - Teacher; - Student; - Parent or Guardian; - Accountant; - Librarian; - Admissions Officer; - Transport personnel; - Health personnel; - ICT personnel; and - other authorised institutional roles.

Permissions may be further restricted according to classes, subjects, departments, students, family relationships and assigned responsibilities.

3. Parent-Child Protection

Parent and guardian access is relationship-based.

A parent account should only be able to view information concerning children properly linked and authorised for that account.

BrightCampus is designed to prevent parents from browsing or accessing unrelated students' private records.

4. Teacher Access Boundaries

Teacher access may be restricted according to teaching assignments and institutional permissions.

For example, a teacher may be authorised to access particular:

- classes; - subjects; - students; - attendance records; - assessments; or - academic activities.

Being a teacher at a school does not automatically mean unrestricted access to every school record.

5. Authentication

Protected BrightCampus services require authenticated access.

BrightCampus applies account and session controls intended to reduce unauthorised access.

Users are expected to:

- keep passwords confidential; - avoid sharing accounts; - use trusted devices where possible; - sign out of shared devices; and - report suspected account compromise promptly.

Additional authentication protections may be introduced as BrightCampus evolves.

6. Secure Communications

BrightCampus production services are intended to use encrypted HTTPS connections so information transmitted between supported browsers, applications and BrightCampus services is protected in transit.

7. Data Protection at Rest

BrightCampus relies on security capabilities provided by its infrastructure and storage architecture to protect stored information.

Sensitive information is subject to additional access restrictions where appropriate.

We continuously review opportunities to strengthen encryption, key management and storage protections as the Platform develops.

8. Password Protection

Passwords and authentication credentials should never be stored as readable plain-text passwords.

BrightCampus authentication systems use secure credential-handling mechanisms designed to prevent retrieval of users' original passwords.

BrightCampus staff should never ask a user to disclose their password.

9. Private Student Files

Student photographs, documents and other private school files are not intended to become publicly accessible simply because they are stored through BrightCampus.

Access to private files should be governed by authentication and authorisation controls.

Public school-website content is treated separately from private institutional records.

10. Public and Private Content Separation

BrightCampus may power both internal school operations and public school websites.

These have different security expectations.

Information deliberately published by an authorised school user may be publicly accessible.

Private information — such as academic records, parent information or internal school data — should remain protected behind appropriate access controls.

11. Sensitive and Medical Information

Where BrightCampus supports medical or other sensitive records, access should be restricted to users with an appropriate institutional need and permission.

Sensitive information should not be exposed merely because a user belongs to the same school.

12. Auditability

Security is not only about blocking access. It is also about understanding important activity.

BrightCampus may maintain logs relating to:

- authentication; - administrative actions; - important record changes; - security events; - system errors; and - other relevant activities.

Audit capabilities will continue to expand as BrightCampus develops.

13. Infrastructure Security

BrightCampus uses professional cloud and technology infrastructure to operate the Platform.

We seek providers offering appropriate safeguards for areas such as:

- hosting; - databases; - file storage; - authentication; - email delivery; - monitoring; and - network security.

Access to production systems should be restricted to authorised personnel and services.

14. Backups and Recovery

BrightCampus seeks to maintain appropriate backup and recovery capabilities for critical production information.

Backup strategy, restoration procedures and disaster-recovery processes are reviewed as the Platform and customer base grow.

15. Secure Software Development

Security considerations form part of BrightCampus development.

Our development practices seek to address areas such as:

- authentication; - authorisation; - input validation; - school isolation; - secure database access; - dependency management; - secrets management; - error handling; - testing; - code review; and - deployment controls.

Security-sensitive functionality should be tested before production release.

16. Environment Separation

Where practical, development, testing and production environments should be separated.

Real school information should not be unnecessarily copied into development or test environments.

Testing systems should use isolated or appropriately sanitised data.

17. Least-Privilege Access

Users, staff and systems should receive only the access reasonably necessary for their responsibilities.

Privileged access should be limited and controlled.

18. Monitoring and Incident Response

BrightCampus seeks to monitor relevant systems for failures, suspicious behaviour and security events.

When a potential incident is identified, our response process may include:

1. investigation;
2. containment;
3. impact assessment;
4. remediation;
5. recovery;
6. appropriate communication; and
7. regulatory or affected-party notification where legally required.

19. Vulnerability Management

No software platform can truthfully guarantee that vulnerabilities will never exist.

BrightCampus seeks to reduce risk through:

- software updates; - dependency maintenance; - security testing; - responsible configuration; - review of identified vulnerabilities; and - timely remediation based on severity.

20. Responsible Security Reporting

If you believe you have discovered a security vulnerability affecting BrightCampus, please report it responsibly.

Do not:

- access information belonging to other users; - download unnecessary personal data; - modify or delete records; - disrupt BrightCampus services; - publicly disclose an unresolved vulnerability in a manner that creates additional risk; or - use a discovered vulnerability for personal gain.

Please provide enough information for us to reproduce and investigate the issue.

Security reports should be sent to:

[[security@brightcampushq.com](mailto:security@brightcampushq.com)]

21. Children's Data Protection

Because BrightCampus operates in educational environments, protecting children's information is a core security and privacy consideration.

We seek to:

- minimise unnecessary collection; - restrict access; - separate public and private information; - protect family relationships; - avoid behavioural advertising based on student records; - maintain appropriate institutional boundaries; and - support schools in meeting their data-protection responsibilities.

22. Privacy by Design

Security and privacy are related but distinct.

When designing new BrightCampus functionality, we seek to consider:

- what information is actually necessary; - who should have access; - how long information should remain; - whether information is sensitive; - whether children are affected; - what should be logged; - what should remain private; and - what could happen if access controls fail.

23. Third-Party Risk

BrightCampus may depend on external infrastructure and service providers.

Before entrusting sensitive processing to a provider, BrightCampus seeks to consider factors such as:

- security practices; - privacy commitments; - reliability; - contractual protections; - data location; - access controls; and - operational necessity.

24. Data Breach Response

Where a personal-data breach occurs, BrightCampus will assess the nature and scope of the incident and take appropriate steps to contain and remediate it.

Where notification is required by applicable data-protection law, BrightCampus will cooperate with affected schools and relevant authorities according to the parties' respective responsibilities.

25. Our Security Philosophy

BrightCampus does not use expressions such as “100% secure” because no responsible internet service can promise that risk has been completely eliminated.

Instead, our commitment is to:

reduce risk, restrict access, protect school boundaries, respond responsibly to incidents and continually improve our security controls as BrightCampus grows.

26. Shared Responsibility

BrightCampus security is a shared responsibility.

BrightCampus is responsible for

Protecting and maintaining the Platform and implementing appropriate safeguards within systems under our control.

Schools are responsible for

Managing authorised users, assigning appropriate permissions, maintaining accurate account relationships and promptly removing access that is no longer required.

Users are responsible for

Protecting their credentials, using accounts appropriately and reporting suspicious activity.

Together, these measures help protect the BrightCampus community.

27. Security Contact

To report a suspected vulnerability or security incident:

BrightCampus Security Team

Email: [[security@brightcampushq.com](mailto:security@brightcampushq.com)]

Website: [www.brightcampushq.com](http://www.brightcampushq.com)

Phone: (+234) 905 012 5594

Phone: (+234) 706 577 7078