Identity
Who is signing in?
SECURITY & TRUST
School access should be powerful — and controlled.
BL TECHNO is designed around authenticated workspaces, role-based permissions, school and centre scope, session controls and traceable access changes. Public marketing, school operations and privileged platform administration remain separate experiences.
Role-Based AccessScoped WorkspacesSession ControlsAudit HistoryProtected Administration
TRUST COREAuthorised accessIdentity
Role
Scope
Action
Audit
01Verify identity
02Resolve role
03Apply scope
04Check action rights
05Protect session
06Record sensitive changes
DEFENCE IN DEPTH
Security is not one switch.
A school platform serves many different people. BL TECHNO's access model is designed to combine identity, role, operational scope, permissions, session controls and auditability instead of relying on a hidden button in the browser.
Role
What responsibility do they have?
Scope
Which school, centre or operational area?
Permission
What action is allowed?
Session
Is the active session still trusted?
Audit
What changed and by whom?
Server-side authority matters.
Browser visibility is useful for user experience, but protected application routes and APIs require server-side authorisation. A hidden menu item is not treated as the security boundary.
ROLE-BASED ACCESS CONTROL
Give users the access their work requires.
School management can separate access by role, module, action and centre scope. The public example below demonstrates the model; each school's final permissions are configured according to its authorised operating structure.
RLRole baselines
Start with a role-aligned access profile instead of configuring every user from zero.
PMModule permissions
Decide which parts of the School App a user may open.
ACAction permissions
Separate viewing from creating, editing, deleting, approving and exporting.
SCCentre scope
Limit operational access to the relevant school or centre context where appropriate.
ILLUSTRATIVE ACCESS MODELPermission Preview
School controlledExample roleAdministrator
Example scopeAssigned school / centres
Illustrative public preview only. Actual permissions are determined by the authorised school configuration and enforced by the protected application.
OPERATIONAL SCOPE
Access can follow the organisation.
Multi-centre schools need more than role names. The user also needs the right operational boundary.
School / Group
Centre AAuthorised team
Centre BAuthorised team
Centre CAuthorised team
ClassesFinanceStaffTransport
School-wide authority
Appropriate senior users can receive authorised access across the school organisation.
Centre-specific authority
Operational teams can be restricted to the centres relevant to their responsibilities.
Role-specific visibility
Being in the correct centre does not automatically grant access to every module or action.
Personal overrides
Where authorised, individual access can be fine-tuned beyond a role baseline.
SESSION SECURITY
MF
PW
CS
TO
Protect access after sign-in, too.
Authentication is only the beginning. Privileged and school-user access can be supported by additional session and account controls.
Multi-Factor Authentication
Privileged roles can be configured to require an additional verification factor.
Password Reset Requirement
Accounts can be required to change their password at the next sign-in.
Concurrent Session Control
Selected users can be restricted from maintaining concurrent sessions.
Idle Timeout
Normalised access policies can include an inactivity window for school-user sessions.
EXAMPLE POLICY VIEWPrivileged Access
CONTROLLEDRequire MFAPrivileged role policy
Concurrent session controlAccount security option
Idle timeoutConfigured access policy
ConfiguredPermission versionAccess-change awareness
TrackedACCESS CONTROLAudit Trail
Traceable changesPermission updatedModule and action rights changed
Role assignment changedUser role context updated
Session security changedSecurity control updated
Centre scope changedOperational boundary updated
Illustrative activity • Demo data only
AUDITABILITY
Know when access changes.
The School App includes an access-control audit trail for user, role, permission and session-security changes. Audit detail can preserve before/after context for review.
Actor / user contextEvent typeTarget userModule contextBefore / after stateTimestamp
Audit availability and retention depend on the deployed product configuration and applicable customer policy.
PRIVILEGED ADMINISTRATION
Platform administration stays outside normal school access.
Global Administration is treated as a separate protected environment rather than another role inside the public portal selector. That keeps platform-level responsibilities apart from school, teacher, student, driver and commercial-partner experiences.
01
Public website explains the product and routes users to the right experience.
02
School application authenticates operational users and applies school access controls.
03
Partner workspace is intended for commercial partner functions, not platform administration.
04
Global Administration remains a dedicated protected sign-in boundary.
PUBLICbltechno.netMarketing & portal selection
↓
SchoolOperational
TeacherAcademic
StudentLearner
DriverTransport
PartnerCommercial
Separate security boundary
◆
PRIVILEGEDGlobal Administration
Dedicated protected sign-in and platform permissions.
DATA PROTECTION PRINCIPLES
Protect the information behind school operations.
Security is broader than login. The product and operating environment should minimise unnecessary exposure, keep customer access scoped and treat sensitive school information as protected data.
School-scoped access
Application access rights are structured per school and can include centre boundaries rather than assuming one shared operational workspace.
Least necessary access
Roles and permissions should give users only the modules and actions needed for their responsibilities.
Secret separation
Production secrets, credentials and privileged configuration should remain outside public website source and client-side code.
Marketing data hygiene
Public screenshots and demonstrations should use fictional or privacy-safe data instead of exposing real learners, parents or financial records.
Data responsibility
Retention, deletion, export and contractual responsibilities should be documented according to the customer's service and jurisdiction.
Vendor & integration review
External services such as payment, messaging or identity providers should be evaluated according to the deployment and market where they are used.
OPERATIONAL TRUST
Security also means resilience.
Enterprise reviews should look beyond permissions and consider how the production environment is operated, monitored and recovered.
AVAvailability
Production services should be deployed with an operational model appropriate to customer scale and service commitments.
Hosting details provided during solution review.BKBackups & Recovery
Backup, restoration and recovery processes should align with production data criticality and agreed operational requirements.
Recovery commitments depend on contracted service level.MNMonitoring
Application health, errors and security-relevant events should be observable so operational teams can investigate problems quickly.
Monitoring scope depends on deployment.CHChange Control
Production releases and sensitive platform changes should follow controlled deployment and approval practices.
Enterprise controls may vary by environment.IRIncident Handling
Security and service incidents need defined ownership, investigation, communication and remediation paths.
Report suspected issues through approved support channels.BCBusiness Continuity
Critical customer operations should be considered when planning recovery, communication and service restoration.
Specific continuity terms belong in customer agreements.
PRIVACY & COMPLIANCE
Compliance depends on evidence — and jurisdiction.
BL TECHNO is intended for schools in different markets, so privacy obligations, contracts, data-processing roles, retention requirements and local regulations cannot be reduced to one worldwide badge.
✓
Jurisdiction-aware reviewEvaluate legal and contractual requirements for the school and deployment country.
✓
Documented responsibilitiesClarify customer and service-provider responsibilities in applicable agreements.
✓
Evidence before claimsPublish certifications, attestations or compliance statuses only when formally obtained and current.
✓
Enterprise due diligenceProvide appropriate security and architecture information during qualified customer reviews.
TRUST PRINCIPLE
No assumed certification badges.
The public website should never imply that BL TECHNO holds ISO 27001, SOC 2 or any jurisdiction-specific certification or legal status unless that claim is formally supported and approved for publication.
When formal certifications or independent attestations are obtained, this Trust page can be updated with the exact scope, issuing body and validity period. Request Security InformationFOR IT & ENTERPRISE TEAMS
Need a deeper security review?
A qualified school or education group may need architecture, access-control, hosting, privacy, integration or operational information beyond what belongs on a public webpage.
01Tell us your environment
Country, organisation size, campuses and technical requirements.
02Define the review scope
Access, integrations, hosting, privacy, procurement or deployment questions.
03Receive approved information
BL TECHNO can provide the information appropriate to the qualified evaluation.
04Document commitments
Any contractual service, privacy or security commitments belong in approved agreements.
SECURITY FAQ
Questions schools may ask during evaluation.
Yes. The School App models module and action permissions, with access that can be aligned to roles and operational scope. Final rights are configured by authorised school administration.
The access-control design supports centre scope so authorised users can be aligned to the centres relevant to their responsibilities.
The existing permission model includes Open, Create, Edit, Delete, Approve and Export actions for mapped School App modules.
The current access-management design includes multi-factor authentication controls and can require MFA for privileged school roles according to configured policy.
The School App includes an access-control audit trail for user, role, permission and session-security changes, with detailed events available for review.
No. Global Administration is intentionally separated from the ordinary public portal selector and uses a dedicated protected sign-in boundary.
This website does not claim certifications that have not been formally verified and approved for publication. Any future certification will be listed with its exact scope and validity information.
Privacy and legal obligations depend on jurisdiction, deployment and contract. Qualified customers should complete the appropriate legal and security review for their market.
Yes. Qualified enterprise and school evaluations can request an appropriate security and architecture review through BL TECHNO sales or support channels.
TRUST THE ACCESS MODEL
Give every user the right workspace — not every workspace.
Explore BL TECHNO with your academic, operational and security teams.