Security
How we approach access, approvals and responsible delivery.
Last updated: 29 September 2026
1. Access follows the work
An implementation should begin with a clear account owner, required permissions and approved scope. Grant the minimum access needed and review it when responsibilities or the engagement change.
2. Account protection
The application includes password hashing, session handling and access checks. Use a unique password, protect recovery access and report suspected unauthorised activity. Security depends on configuration and ongoing verification as well as code.
3. Client and internal access
Client data should remain scoped to that client. Internal roles and capabilities govern sensitive access. New integrations and workflows must be reviewed for their data access and approval boundaries before use.
4. Consequential actions
Changes that affect spending, customer communications or important business records require agreed authorisation. A recommendation is not blanket permission to execute. Each implementation should state what is automatic, what requires approval and how access can be revoked.
5. Integrations and reliability
Provider credentials belong in server-side configuration. Webhooks, payment flows and external connections require validation and correct configuration. Backup, monitoring and recovery arrangements need to be verified for the deployment; this page does not promise uninterrupted service or certify an audit.
6. Report a concern
Email raftaar.saas@gmail.com with a description and safe reproduction steps. Do not include passwords, full customer records or payment details. Avoid accessing other users’ data or disrupting the service while reporting an issue.