Ceus Solutions
Our approach

Protecting your business records.

Encryption, controlled access and tested recovery protect different parts of your business. We’ll explain the controls and agree what your system needs before we build it.

Choose who can change your records.

A salesperson can view an invoice while Finance records its payment. Switch roles below to see how the same record behaves for different staff.

Staff permissions · invoice accessInteractive example

Choose a staff role

This example uses local permission rules. Production permissions must also be enforced and tested on the server.

INV-3091Unpaid

Evergreen Builders

S$2,592

Sales has view-only access

Try recording a payment to see the permission check, then switch to Finance.

Adapted from Ceus One Demo · fictional data · no live transactions

Role-based access control (RBAC). Your team agrees the permissions; the application must enforce them on the server.

Know how your business gets back to work.

A restore test should end with an invoice you can open, totals you can check and files you can retrieve. We agree the recovery targets, then test against them.

Backup copyRecords, files and configuration

Restore in a separate environment

INV-3091Recovered copy

Evergreen Builders

S$2,592

  • Open the invoice
  • Compare the total
  • Retrieve its attachments
Illustrative recovery sequence using fictional records. Actual results are recorded during your project’s restore test.
Recovery point objective (RPO)
Agree how much recent work could be lost between the last recoverable copy and an incident.
Recovery time objective (RTO)
Agree the target time to bring a usable system back, then measure it in a restore test.
See the review documents

Keep control of your system.

Before work starts, we agree what you own, what you can export and what another provider would need to take over.

  • Accounts and access

    A record of who owns each account, how you access it and how Ceus’s access can be removed.

  • Records and exports

    An agreed list of downloadable records and attachments, with a sample export your team can check.

  • Code and handover

    Written terms covering code ownership or licences, operating instructions and services the system depends on.

How the protection fits together.

Defence in depth puts checks at each stage, from signing in to storing a record. These are the controls we scope and verify for your project.

  1. Your team

    MFA & FIDO2 passkeys

  2. The connection

    TLS 1.3

  3. The application

    Server-side RBAC

  4. Your records

    AES-256 & key management

Providers, settings, responsibilities and exceptions are agreed in your proposal and checked before launch.

  • Account protection

    MFA · FIDO2 / WebAuthn passkeys · Argon2id

    A stolen password should not be enough to take over an administrator’s account.

  • Staff permissions

    RBAC · Least privilege · Tenant isolation

    Use role-based access control to limit actions by job, and tenant isolation to keep each organisation’s records separate in a shared system.

  • Data encryption

    TLS 1.3 · AES-256 · Key management (KMS)

    Protect customer records, invoices and files while they travel between systems and while they are stored.

  • Files & credentials

    Secrets vaults · Credential rotation · Signed URLs

    Keep service credentials out of browser code and source control. Use expiring, signed download links for private files where supported.

  • Traffic protection

    WAF · API rate limiting · DDoS mitigation

    Combine a web application firewall with request limits to reduce malicious traffic, repeated sign-in attempts and abuse of expensive API actions.

  • Security testing

    OWASP ASVS · SAST / DAST · SCA

    Test for SQL injection, cross-site scripting (XSS) and broken access controls, alongside source-code and dependency scans.

  • AI safeguards

    Permission-aware RAG · Prompt-injection testing · Tool allowlists

    Retrieval-augmented generation (RAG) must check access before fetching records. Restrict AI actions to approved tools and require human approval for consequential changes.

  • Audit trails & response

    Audit trails · Event correlation · Incident response

    Make important changes traceable and give the team a clear course of action when an alert arrives.

  • Backup & recovery

    Disaster recovery · RPO / RTO · PITR assessment

    Agree recovery targets, then assess point-in-time recovery (PITR) to restore a database to a chosen time where supported.

The full outline includes implementation checks and acceptance evidence. Independent testing and support coverage are scoped separately.

Read the full review outline

See what your team reviews.

These sample documents show the decisions and checks to record for your project. They use fictional data or blank fields.

Client checklist (PDF)Full review outline (TXT)
Ceus SolutionsSample document

Staff access matrix

Ceus One example / Invoice permissions

Agree which roles can view records and approve changes.
RoleView invoicesRecord payment
ManagerAllowedAllowed
SalesAllowedDenied
FinanceAllowedAllowed
Negative test
A direct payment request from Sales must be refused by the server.
Positive test
Finance can record a payment and the action appears in the audit trail.

Your owner approves the roles; the delivery team records the server-test results before launch.

Illustrative only. No client data or completed audit.

Printable sample · 1 pageDownload sample (PDF)

Questions about your data.

You or your technical adviser can review the controls, provider choices and verification results with us.

What is SHA-256 used for?

SHA-256 creates a digital fingerprint, or hash, of information. Comparing it with a trusted original can help check whether a transferred file has changed. It does not encrypt the file or keep its contents private. For migration, file checksums can complement record counts and balance checks. Passwords need a dedicated password-hashing method, such as Argon2id; plain SHA-256 is not suitable for password storage.

Where will our information be stored?

We’ll explain the proposed storage location, services that receive your records and who can access them. The project checks cover encryption during transfer and storage, and removing access granted to Ceus or other providers. Cloud hosting protects part of the system; we’ll also document the responsibilities of Ceus, your team and the hosting provider.

Will AI use our confidential information?

Only the sources agreed for the AI feature should be available to it. We’ll document what leaves your system, which provider receives it, where it is processed and the account’s retention and training settings. Customer records, internal documents and message history need separate decisions. A promise that data is not used for training does not, by itself, mean the provider retains nothing.

Can you meet our security requirements?

Share your requirements during discovery so we can assess the fit. Independent testing, specific certifications, private hosting or regulated workloads need separate assessment and scope. A hosting provider's certification does not certify the application built on it.

Start with the problem.

No brief or technical diagnosis required.

Tell us what's stuck