Row-Level Security everywhere
Enabled on every table in the database. A query cannot return a row the requesting session is not entitled to — enforced by PostgreSQL itself, not by application code that can be bypassed.
Trust & Security
Security you can put in a tender document
Trainee NIDs, assessment records, beneficiary lists — institutional data deserves institutional protection. This page sets out exactly how NUSAIFA IT systems are built, what we can evidence on request, and what we do not claim.
24/24
Tables with Row-Level Security enabled
60+
Validated server functions handling all access
0
Direct table access paths from client code
12h
Maximum session token lifetime
Figures describe the hardened v4.1 release of our production Training Management System — the same architecture our other products are built on.
Architecture
Eight controls that sit between an attacker and your records
Most breaches are not exotic. They happen because an application talks to the database with more privilege than it needs. We removed that possibility at the architecture level, not with a policy document.
No direct table access
Client code has zero table and sequence privileges. Every read and write passes through a named, validated server function. There is no path to raw SQL from the browser.
Anonymous access revoked
The public API key, on its own, can read nothing. Even if it were copied from the page source, it grants no data — only the ability to call authenticated functions.
Passwords hashed with bcrypt
Stored one-way, never reversible, never written to logs. Nobody at NUSAIFA IT — including us — can read a user's password.
Expiring session tokens
Sessions carry a 12-hour maximum lifetime, and a scheduled routine purges expired sessions. A forgotten login on a shared office computer stops being a risk overnight.
Login throttling
Five failed attempts within fifteen minutes locks further tries on that account. Password-guessing at scale is not economical against the system.
Locked document storage
Uploaded certificates, NID copies and inspection files cannot be altered or deleted by client-side code. Storage policies are separate from, and stricter than, table policies.
Complete audit log
Who changed which record, and when. Result approvals, role changes and document removals are all attributable to a named user — which is what an auditor actually asks for.
Encrypted transport
SSL/TLS end to end. Data is encrypted in transit between the browser, the application and the database — and at rest by the hosting platform.
Access control
Everyone sees their own work — and nothing else
Role-based access is configured to your organisation chart during setup. The table below shows a typical TVET institute configuration; yours can differ.
| Role | Can see | Can change | Cannot do |
|---|---|---|---|
| System administrator | All records in the institution | Configuration, users, roles | Read passwords; edit the audit log |
| Programme / institute admin | All trainees, batches, results | Admissions, batches, approvals | Change system configuration or roles |
| Trainer / assessor | Only assigned batches | Attendance, scores for those batches | See other trainers' batches; approve final results |
| Trainee / student | Only their own record | Nothing — read and download only | See any other trainee's data |
| Auditor | Records plus the full audit trail | Nothing — strictly read-only | Modify or delete any record |
| Donor / M&E viewer | Aggregated indicators and reports | Nothing | Open individual trainee records |
Data ownership
Your data belongs to your institution
- You own every record in your instance — we operate it, we do not own it
- Full export in standard formats (CSV / SQL) on request, at any time, including on exit
- We do not sell, rent or share your data with any third party
- We do not use your institution's data to train AI models or build datasets
- Personal data is collected only where a workflow genuinely requires it
- Retention and deletion follow your written instruction, not our convenience
- NUSAIFA IT staff access production data only for support, only with your request logged
- Privacy-first and GDPR-aligned principles applied by default, including for donor-funded programmes
Availability
Backup, recovery and continuity
Daily automated backups
Taken every day without manual intervention, retained on a rolling schedule, and restorable to a point in time.
Recovery tested, not assumed
A backup nobody has restored is a rumour. We run periodic restore drills so recovery time is a measured number, not a hope.
Incident response
A named contact, a defined escalation path, and written notification to your institution if an incident affects your data.
Hosting choice is yours on the Enterprise plan — our managed cloud, your organisation's cloud account, or infrastructure you nominate. Uptime commitments and response times are written into the Enterprise SLA. See packages.
How we build
Security-first development, in sequence
- Least privilege is the default state, not a hardening step done later
- Database migration and security scripts are idempotent and parser-validated before release
- No credentials, keys or secrets are ever placed in client-side code
- Every input is validated server-side, regardless of what the browser already checked
- Changes ship as versioned releases with a written change log (current: TMS v4.1, security-hardened)
- Architecture is audited before refactoring — we map the system before we change it
For procurement teams
What we supply for a tender or RFQ
Government and donor-funded procurement asks specific questions. These documents are available to shortlisted institutions on request, under NDA where you require one.
Technical specification
System architecture, module list, technology stack, integration points and capacity figures in the format your evaluation committee expects.
Security architecture summary
A written description of the controls on this page, at the level of detail an IT security reviewer needs to score a bid.
Role & permission matrix
Mapped to your actual organisation chart, so the reviewer can see exactly who would hold which privilege.
Data processing undertaking
Written confidentiality and data-handling commitments, adaptable to your donor's or ministry's standard clauses.
Backup & continuity statement
Backup frequency, retention, restore procedure and responsible party, stated in writing.
Security questionnaire responses
We complete your vendor security questionnaire directly. Where the honest answer is "not yet", we write "not yet".
Honest limits
What we do not claim
A security page that claims everything is worth nothing. Here is where we currently stand, stated plainly — so nobody discovers it halfway through an evaluation.
No ISO 27001 or SOC 2 certificate
We hold neither today. If your tender requires a certified vendor, we will tell you at the first call rather than let you spend evaluation time on us.
Third-party penetration testing
Not included as standard. We will commission an independent test as a scoped, priced engagement where a programme requires one.
Two-factor authentication
Not yet in the standard product. Current protection is bcrypt hashing, expiring tokens and login throttling. 2FA is on the roadmap below.
Air-gapped on-premise deployment
Available only under Enterprise scoping with your infrastructure team, not as an off-the-shelf option.
Formal ISMS documentation
Our practices are consistent and documented per release, but we do not yet operate a formally certified information security management system.
Uptime guarantees below Enterprise
Starter and Professional plans receive best-effort availability. A contractual uptime commitment exists only in the Enterprise SLA.
Roadmap
What we are working on next
Two-factor authentication
SMS and authenticator-app second factor for administrative roles first, then all staff accounts.
Independent penetration test
A scoped external assessment of the production platform, with the summary made available to enterprise clients.
Formal ISMS documentation
Written policies, asset register and incident procedures, structured towards a future certification path.
Client-facing status page
A public page showing system availability and maintenance windows, so you do not have to ask.
Responsible disclosure
Found a vulnerability? Tell us.
Email info.nusaifaitbd@gmail.com with the subject line SECURITY, or call the hotline. We acknowledge within two working days and keep you informed until it is resolved.
- We will not pursue legal action against good-faith security research
- Please give us reasonable time to fix an issue before publishing it
- Please do not access, modify or delete data belonging to any institution
- Credit is given to reporters who wish to be named
Questions
Security FAQ
Where is our data physically hosted?
On Starter and Professional plans, in managed cloud infrastructure we operate. On Enterprise, hosting location is your decision — our cloud, your organisation's cloud account, or infrastructure you nominate, including in-country hosting where a donor or ministry requires it.
Can we host the system on our own servers?
Yes, under the Enterprise plan and with your infrastructure team involved in the scoping. We hand over deployment documentation so your staff are not dependent on us to operate it.
Who at NUSAIFA IT can see our records?
Access to production data is limited to the support engineers assigned to your account, and only when you have raised a request. Every access is attributable through the same audit log your own administrators can read.
What happens to our data if we stop using the system?
You receive a complete export in CSV and SQL formats. After you confirm you have it, we delete the production data on your written instruction and confirm the deletion in writing.
Will you complete our donor's security questionnaire?
Yes. Send it across and we will complete it directly, including the questions where the answer is a limitation rather than a capability.
How do you handle staff who leave our institution?
Your administrator deactivates the account, which immediately invalidates the session token. The person's historical actions remain in the audit log — deactivation removes access, it does not erase accountability.
Is the system tested against OWASP-type risks?
The architecture removes several classes outright — no client-side SQL access, server-side validation of every input, no secrets in browser code, throttled authentication. We do not, however, claim an independent OWASP assessment; see "What we do not claim" above.
Can we get a copy of the audit log for an external audit?
Yes. The audit trail exports for any date range in a format your auditor can work with, and read-only auditor accounts can be issued for the duration of an audit.
SSL/TLS encryptedRow-Level SecurityDaily backup
Full audit logbcrypt hashingExpiring sessions
Login throttlingYour data, your ownership
Bring your security reviewer to the demo
We are happy to spend the session on architecture, roles and audit trails rather than screens. Documentation follows in writing afterwards.
Request a demo Contact us