CEUS SOLUTIONS — SECURITY REVIEW OUTLINE ---------------------------------------- Project planning guide · 22 September 2026 ---------------------------------------- This outline describes requirements to scope and verify. It is not a completed client report, certification or proof that controls are deployed. Agree providers, owners, costs, exclusions and acceptance evidence for your project. ---------------------------------------- 1. 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. CHECKS - Check the browser, application, database and connected services for encrypted connections. Prefer TLS 1.3; allow TLS 1.2 only where compatibility requires it, with older protocols disabled. - Specify storage encryption for the database, uploaded files and backups separately. Assess AES-256 with each provider and record the actual configuration and any gaps. - Use the provider’s key management service (KMS), or an agreed equivalent, to restrict key access. Name the key owner and agree rotation and recovery procedures. Keep keys separate from the data they protect. BEFORE SIGN-OFF Check live endpoints and provider settings against the agreed design. An HTTPS padlock alone does not demonstrate that database files or backups are encrypted. WHAT YOU RECEIVE A data-flow diagram, encryption settings for each service and a key-access record. ---------------------------------------- 2. ACCOUNT PROTECTION MFA · FIDO2 / WebAuthn passkeys · Argon2id A stolen password should not be enough to take over an administrator’s account. CHECKS - Require multi-factor authentication (MFA) for privileged access to the application, hosting, source code, database and backups. Prefer phishing-resistant FIDO2 / WebAuthn passkeys or security keys where supported, with a named account for each person. - Use maintained sign-in services. For a new password store, prefer Argon2id with unique salts and a reviewed work factor; verify the chosen provider’s password-storage method. - Set session expiry and secure session-cookie settings. Test single-use, expiring reset links, MFA recovery and removal of active access when a staff member leaves. BEFORE SIGN-OFF A removed user’s existing session must lose access, and password recovery must not provide a way around the agreed MFA checks. WHAT YOU RECEIVE The account inventory, sign-in settings and results for enrolment, recovery and access removal. ---------------------------------------- 3. 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. CHECKS - Build an access matrix around real jobs: for example, warehouse staff can update stock while payroll and supplier bank details remain restricted. - Enforce permissions on the server for individual records, organisations, file downloads and background jobs. A hidden button is not an access check. - Deny access unless a rule allows it. Limit administrator privileges and review the accounts used by integrations as well as staff. BEFORE SIGN-OFF Try another customer’s record ID in a direct request, download a restricted attachment and attempt an approval with a read-only account. Each must be refused. WHAT YOU RECEIVE Your approved access matrix and test results for allowed and forbidden actions. ---------------------------------------- 4. 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. CHECKS - Keep API keys, database passwords and access tokens in an approved secrets store, outside browser code and source control. Restrict each credential and define how it is rotated or revoked. - Keep production access separate from development and testing. Use synthetic or redacted test records unless a restricted copy is explicitly agreed. - Keep private file storage closed to public access. Authorise each request before issuing a time-limited signed URL where supported. Treat the URL as a bearer credential and agree retention and deletion rules. BEFORE SIGN-OFF An unauthorised visitor cannot fetch a private attachment, an expired download link stops working, and a credential scan finds no unresolved exposed secrets in the release. WHAT YOU RECEIVE A storage-access review, secrets scan and record of environments, data locations and retention decisions. ---------------------------------------- 5. 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. CHECKS - Record the hosting provider’s firewall and distributed denial-of-service protection, which endpoints it covers and which features need a paid plan. - Set request limits for sign-in, password recovery and relevant APIs, including exports, imports and AI actions. Choose limits around expected use and the cost of abuse. - Use suitable account, session or network limits and monitor rejections. Check that staff sharing an office connection can still work normally. BEFORE SIGN-OFF In a controlled test, requests beyond the agreed limit are blocked or delayed while ordinary staff activity still succeeds. Provider coverage alone does not prove application limits work. WHAT YOU RECEIVE Configured rules, service-plan coverage and recorded rate-limit tests. Availability commitments are agreed separately. ---------------------------------------- 6. 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. CHECKS - Select applicable requirements from the OWASP Application Security Verification Standard (ASVS). Record the version, test scope and acceptance criteria; referencing ASVS does not claim full conformance or certification. - Review database queries and untrusted page content for SQL injection and cross-site scripting (XSS). Check request-forgery protection where the sign-in design requires it. - Scope static application security testing (SAST) for source code, dynamic application security testing (DAST) against an authorised test environment, and software composition analysis (SCA) for vulnerable dependencies. Check file-upload restrictions and exposed credentials too. - Give findings an owner and a severity, record fixes and retest them. Scope an independent penetration test separately when the buyer or workload requires one. BEFORE SIGN-OFF Material findings are fixed and retested before launch. Any accepted exception records its impact, mitigation, owner and review date; an automated scan is not a penetration test. WHAT YOU RECEIVE The ASVS requirement list, scan findings and retest results; an independent penetration-test report when scoped. OWASP guidance is not a certification. ---------------------------------------- 7. 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. CHECKS - Agree events such as failed sign-ins, permission changes, exports, deletions and financial approvals. Record who acted, when, which record was affected and whether the action succeeded. Use request or correlation IDs to trace related events across services. - Restrict log access and set retention. Keep passwords, access tokens and unnecessary personal information out of logs; protect audit history from routine users changing it. - Name alert recipients, coverage hours and escalation contacts. Document how to revoke sessions, rotate exposed credentials, isolate a service and update the client during an incident. BEFORE SIGN-OFF Trigger an agreed test event, confirm that the audit entry is useful and check that its alert reaches the responsible person. Round-the-clock monitoring requires an agreed staffed service. WHAT YOU RECEIVE Sample audit events, an alert-delivery result and an incident-response guide with named owners. ---------------------------------------- 8. 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. CHECKS - Set the recovery point objective (RPO), the acceptable data-loss window, and recovery time objective (RTO), the target time to resume. For example, a 1-hour RPO and 4-hour RTO are targets to price and test, not a Ceus service promise. - List everything needed to recover: database records, uploaded documents, configuration and access to required keys. Set backup frequency, retention and protection from deletion by routine application accounts. - Assess point-in-time recovery (PITR) where the database supports it: restoring to a selected time using retained backups and transaction logs. Confirm the recovery window, service cost and separate recovery of files and connected systems. - Restore into an isolated environment before launch and agree repeat tests. Check the restored data’s timestamp, attachments, record totals and important tasks such as opening an invoice. BEFORE SIGN-OFF Measure the actual time to restore usable service and the gap to the latest recovered records. Compare both with the agreed targets; a successful backup notification is insufficient. WHAT YOU RECEIVE A dated restore report, measured recovery results, backup settings and the next test owner and date. ---------------------------------------- 9. 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. CHECKS - Apply user and organisation permissions before retrieving documents or records. Agree the provider, permitted data, retention and training settings for each AI feature. - Treat messages, uploaded files and retrieved instructions as untrusted. Test attempts to make the assistant reveal another customer’s data or misuse a connected tool. - Allowlist the tools available to each AI feature and validate their inputs and permissions on the server. Require the agreed human approval for refunds, payment-detail changes, deletions or external messages, with limits on spending and repeated actions. BEFORE SIGN-OFF A document telling the AI to ignore its rules must not grant extra access or approve a restricted action. Check refusal and escalation behaviour as well as successful tasks. WHAT YOU RECEIVE An AI data-and-tool inventory, permission and misuse test results, and the approval rules for consequential actions. ---------------------------------------- PROJECT REVIEW RECORD Project: ____________________ Technical owner: ____________________ Client decision-maker: ____________________ Agreed scope and exceptions: ____________________ Evidence reviewed: ____________________ Open actions, owners and dates: ____________________ Approval and date: ____________________ ---------------------------------------- Contact: contact@ceuscapital.com · +65 8347 2758 Please arrange a restricted transfer channel before sharing confidential records.