Demo data boundary
Safe
No real student, staff, finance, or payment data.
Security Trust CentreProduction planningDemo University Malaysia
Security & PDPA Trust Centre
A presenter-safe trust page for access control, audit logging, PDPA-aware data protection, secure uploads, exports, migration, and deployment hardening.
Current environment
Prototype / demo data
Production state
Planned, not yet implemented
Purpose
Stakeholder readiness briefing
Authentication
Planned
Production login, SSO, MFA, and secure sessions are future scope.
Role access
Defined
Student, Lecturer, Admin, and Executive access model is separated.
Audit readiness
Prepared
Audit log surfaces exist for demo and will require backend persistence.
Secure uploads
Future
File validation, private storage, signed URLs, and scanning are production scope.
Deployment controls
Future
Production monitoring, backups, secrets, and rollback need IT approval.
Trust Centre Snapshot
A concise view for IT Head, management, and data protection discussions.
Role-Based Access
Student / Lecturer / Admin / Executive
Each role has a separate shell, navigation model, and future backend permission boundary.
PDPA-Aware Records
Mask, restrict, audit
Sensitive student identity, finance, guardian, grade, and support records require access logging and masking rules.
Workflow Traceability
Before / after audit
Approvals, payments, attendance, grade release, and document actions are designed for traceability.
Production Boundaries
Demo-safe now
No real gateway, production API, private file storage, or real institution data is connected in this prototype.
Role Access Model
What each role should be allowed to view or operate in production.
Student
Own records only
Profile, finance, attendance, requests, documents, results
Lecturer
Assigned teaching scope
Classes, attendance verification, grading, assigned student 360
Admin
Operational permissions
Approvals, finance verification, users, audit, reports, communications
Executive
Read-only institution view
Enrolment, financial performance, risk, operations, trends
PDPA-Aware Data Handling
Sensitive record categories and expected protection approach.
Identity data
Student ID, contact, guardian, and document metadata require role-based visibility.
Academic data
Grades, CGPA, transcripts, appeals, and release actions require academic permission boundaries.
Finance data
Outstanding fees, receipts, proof status, and clearance data require finance-role controls.
Support data
Student affairs, counselling, complaints, and exception requests require restricted case access.
Exports
CSV/PDF exports should include generated-by metadata, date range, role, and masked fields by default.
Audit & Evidence Readiness
Demo surfaces already show how future production evidence should be reviewed.
Audit Trail Viewer
Before/after values, actor, role, device, timestamp, severity, and selected event timeline.
CampusFlow Pay sandbox
Payment method simulation, receipt preview, local audit events, and notification preview.
Approval Center
Decision owner, proof, status timeline, queue controls, and workflow outcome state.
Attendance Data Pool
Check-in method, verification state, lecturer actions, remarks, and export readiness.
Production Security Control Areas
Controls to approve before production go-live.
Authentication & Session Security
Production requirement
- Central secure authentication service
- Role-verified redirects after login
- Password hashing and reset workflow
- Optional SSO / Microsoft Entra ID
- Optional MFA or OTP for staff roles
- Session expiry, logout, and failed-login protection
Role-Based Access Control
Backend enforced
- Student can view and submit own records only
- Lecturer can access assigned classes and academic workflows
- Admin can manage operations based on permission
- Executive is read-only for institution-level analytics
- Backend APIs must verify every permission
- Frontend route guards are not sufficient alone
PDPA-Aware Data Protection
Data protection
- IC/passport, phone, email, and address masking where needed
- Guardian data access restrictions
- Finance and grade access restrictions
- Audit of sensitive record views
- Privacy notice and consent workflow
- HTTPS-only production traffic
Audit Logging
Traceability
- Login/logout events
- Payment verification actions
- Document upload and download events
- Course registration and approval decisions
- Attendance open, close, cancel, and manual updates
- Grade release, adjustment, user, role, and export events
Demo Boundary
What to say clearly during the pitch.
Demo data only
The current app does not contain real student, staff, finance, grade, or payment data.
No real gateway
CampusFlow Pay is sandbox/mock only and does not connect to a production payment provider.
No production backend yet
Authentication, database, APIs, secure uploads, exports, and audit persistence are production scope.
Security planning is visible
This page documents the required controls so IT and management can validate the path to production.
Implementation Tracks
Security workstreams for the future production phase.
Secure File Uploads
- PDF/JPG/PNG allow-list
- File size limits
- Server-side validation
- Malware scanning if available
- Private storage
- Signed download URLs
- Upload/download audit trail
Export & Report Controls
- Permission-based exports
- Export audit logs
- Date range limits
- Masked fields by default
- Generated-by metadata
- No public export URLs
- Approved PDF templates
Environment & Git Safety
- No API keys in Git
- No .env committed
- Use .env.example only
- Secrets stored in server environment
- Private production repository
- Secret scanning
- Restricted deployment access
Deployment Security
- Staging/UAT environment
- Production environment
- Monitoring and logging
- Backups
- Rollback plan
- Institution IT access policy
- Approved go-live checklist
PWA, Camera & Push Notification Readiness
Installable PWA baseline is connected for Vercel testing. Camera permissions and push delivery remain future production scope.
PWA Install
Install baseline connected
Manifest, icons, service worker registration, and offline fallback are connected for Vercel testing.
Camera Access
Permission gated
Future camera permission for QR attendance, ID card scan, MC slip capture, and library barcode scan.
QR / Barcode Workflows
Planned
Student check-in, staff verification, student ID scan, and library barcode workflows can reuse this layer.
Push Notifications
Production scope
Class cancelled, payment approved, MC decision, ID card ready, announcement, and admin approval alerts.
Data Migration & Cutover Strategy
Recommended path for moving from existing systems to CampusFlow.
Existing systems should remain active while CampusFlow is prepared. Migration should move through staged import, validation, parallel run, approved cutover, and read-only legacy backup.
Stage 1
Data discovery
Stage 2
Field mapping
Stage 3
Data cleansing
Stage 4
Test migration
Stage 5
UAT validation
Stage 6
Parallel run
Stage 7
Final cutover
Stage 8
Old system read-only backup
Production Implementation Roadmap
Clear future phases after stakeholder approval.
Phase 3.0
Backend, Authentication & Database
Secure accounts, role verification, schema, and protected API routes.
Phase 3.1
Migration & Integration
Source-system discovery, data mapping, test import, and integration checks.
Phase 3.2
Security Hardening
Audit persistence, secure uploads, export permissions, and secret management.
Phase 3.3
UAT & Production Deployment
Staging review, UAT fixes, approved deployment, and handover.
Phase 3.4
Support & Maintenance
Monitoring, issue triage, staff training, and maintenance releases.
Route Shortcuts
Useful pages for the presenter and IT review discussion.