Is every capability applied in every project?
Controls and practices are chosen according to the project's scope, data sensitivity and operating environment, and are fixed in the scope document so the institution knows exactly what it will receive.
Capabilities
Institutional capabilities that support delivery and technical proposals
The working practices SysTrac applies when analysing, building and delivering institutional systems. Controls are detailed according to the institution's sensitivity, the system's scope and the contract.
Capabilities and method
What we apply throughout a project
API integration
Documented interfaces and controlled data exchange with existing systems. Failure handling, ownership and responsibilities are defined up front.
Permissions & roles
The least privilege each role needs, with duties separated by module, screen and sensitive action. Permissions are enforced on the server, not only hidden in the interface.
Audit trails
Tracking sensitive operations, who performed them and when. This supports administrative review and accountability.
Flexible hosting & operations
Cloud hosting or the institution's own servers, according to its policy. Operating responsibilities are documented either way.
Backup & recovery
Scheduled backups and a recovery procedure that is tested. Frequency and retention follow data sensitivity and continuity needs.
Documentation & handover
Functional and technical documents, user guides and operating guides. They support acceptance, maintenance and transfer of the system.
Training & knowledge transfer
Training for the real user groups and administrators. The institution receives the knowledge it needs to manage and run the system internally.
Application security in development
Permission design, identity and session controls, logging of sensitive operations, dependency checks and testing before launch. Controls are matched to the project's scope and data sensitivity.
Capabilities and tenders
Technical proposal outputs a committee can review
We link each requirement to the solution, output and evidence.
- A documented understanding of the need and scope
- A requirements compliance matrix
- Solution, architecture and integration plan
- Phases and acceptance outputs
- Testing, training and operations plan
- Clear assumptions, exclusions and pricing
Frequently asked questions
Before you start
Do you hand over documentation, code and data?
Code ownership, licences, documentation and the data handover method are defined in the contract. The institution's data remains its own, and access, backup and recovery arrangements are documented.
How are operations and support levels defined?
By environment, support hours, incident priority, response times and responsibilities, all set out in a written operating agreement.
How do you approach a large project or tender?
We convert the requirements into a compliance matrix, phases and acceptance outputs, then link design, implementation, testing, training and operations to the agreed scope.
Need a technical proposal or capability details for your institution?
We review the documents, environment and scope, then define the right outputs and evidence.