Security at ChapFlow

How we approach security

ChapFlow is a product of The Site Weavers (https://www.siteweavers.co.tz), which operates the platform and is accountable for the controls described here.

Section 27 of the Personal Data Protection Act, 2022 (Cap. 44) requires safeguards that are reasonable in the circumstances, judged against the state of technology, the cost of implementation, the nature of the data and the risk to the people it describes. We build to that standard, and we prefer to be precise about what is in place rather than reassuring in the abstract.

Three principles shape the platform:

• Isolate by default. Separation between customers is structural, not a filter applied by application code that someone could forget to write.
• Least privilege everywhere. Users, roles, plan entitlements, API tokens and our own support staff all get the narrowest access that still works.
• Make actions accountable. Sensitive actions, including our own administrative access, are written to logs you can inspect.

Tenant isolation

• ChapFlow is multi-tenant, and each workspace is provisioned with its own dedicated database. Your records are not co-mingled with another customer's rows, so a missing filter in application code cannot expose one customer's data to another.
• Platform-level data lives in a separate central database, distinct from every workspace database.
• A workspace is identified by its domain on every request. Tenant context is established before authentication and authorisation run, so a request cannot be authorised in the wrong context.
• Cache entries, queued background jobs and file storage are all scoped per workspace, so cached values, jobs and uploads cannot leak across boundaries.
• Middleware prevents workspace routes from being reached on our central administrative domains, and prevents central routes from being reached through a workspace domain.
• Workspace provisioning, migration and permanent deletion are automated, so a deleted workspace has its database dropped rather than being left dormant.

Authentication

• Passwords are stored only as bcrypt hashes with a strengthened work factor. We cannot read your password, and neither can anyone who obtains the database.
• Two-factor authentication using time-based one-time codes is available to every user, with single-use recovery codes for lost devices. The shared secret is stored encrypted.
• Optional single sign-on with Google or LinkedIn is supported, and two-factor authentication still applies when it is enabled on the account.
• Password reset links expire after 60 minutes, and requesting a new one is throttled.
• Session data is encrypted, sessions expire after a period of inactivity, and central and workspace sessions use separate cookies scoped to their own domains so one cannot be replayed against the other.
• Expired sessions and stale request tokens are handled by clearing the session and returning the user to sign-in rather than failing into an ambiguous state.

Authentication and recovery endpoints are rate limited to blunt credential-stuffing and brute-force attempts. Sign-in, two-factor challenge and password-reset attempts are each throttled to a small number of tries per minute, counted against the account and the originating network together so that neither a single address nor a single account can be hammered. Public marketing forms add timing and honeypot checks on top of throttling. We publish the fair-use limits that developers need in our Terms of Service, and we deliberately do not publish the exact thresholds for authentication endpoints.

Authorisation and access control

• Role-based access control governs every workspace. Administrators define roles, assign granular permissions, and change them as people join and leave.
• Platform administration uses a separate permission set and a separate authentication guard from workspace users, so a workspace role can never grant platform-level power.
• Authorisation policies are enforced per record across the CRM, projects, people, commercial, storage and reporting domains, so a user who can reach a page still cannot reach a record they have no right to.
• Plan entitlements and feature flags gate whole modules at the routing layer, before any controller runs.
• Workspace API keys are stored only as hashes, carry an explicit list of abilities, and can be given an expiry date. A key is shown once at creation; afterwards only its prefix and last-used timestamp remain visible, so a leaked database does not yield usable keys.
• A suspended organisation is blocked at the middleware layer from everything except the billing pages needed to restore service.

Support access and impersonation

Silent administrative access is one of the biggest risks in any hosted platform, so we constrained it deliberately. When our support team needs to see what you see in order to resolve a ticket:

• the staff member must hold a specific platform permission that is not granted by default;
• access requires a single-use authorisation that expires after five minutes, and it is checked against the target workspace so it cannot be redirected elsewhere;
• a visible banner is displayed inside the workspace for the whole session, so your users can see that a support session is active; and
• the start and the end of the session are written to our platform audit log, which we can produce for you on request.

Encryption and secrets

• All traffic to the Service is served over HTTPS with TLS. Application URLs are generated over HTTPS in production, and connections to our sub-processors are encrypted in transit.
• Particularly sensitive values are encrypted at the application layer using authenticated symmetric encryption, including social and integration access and refresh tokens, automation secrets, third-party API keys stored in settings, and two-factor secrets.
• Session payloads are encrypted rather than stored as readable data.
• Private files are never served from a public path. Access is granted through signed links that expire, by default after one hour, and object storage buckets are configured as private.
• Credentials and provider keys are supplied through environment configuration and are never committed to source control.
• Encryption of the database volume at rest is provided by the hosting infrastructure. We will confirm the configuration for your deployment in writing on request.

File upload and storage security

• Uploads are validated against an allowed list of content types, and executable, script and other dangerous file types are rejected outright rather than being filtered by name.
• Per-file size limits apply, and each workspace has a storage quota tied to its plan that is checked before a write is accepted.
• Files are stored on private disks, or in a private object-storage bucket, and are addressed by opaque object keys rather than guessable paths.
• Downloads go through a signed, expiring route that re-checks the requesting user's authorisation.
• Deleting a file also removes it from the AI knowledge index, so deleted content does not linger in search results.

API and webhook security

• The API authenticates with bearer tokens issued per device, and tokens can be revoked individually. Signing out deletes the token used for that session.
• Sensitive commercial write operations accept an idempotency key, so a retried request cannot create a duplicate invoice or payment.
• Inbound webhooks are rate limited and, where the provider supports it, cryptographically verified before we act on them.

We treat every inbound callback as untrusted input regardless of its signature. Before acting on a payment or status change, we look the transaction up with the provider over an authenticated outbound connection and act on that authoritative response rather than on the body of the callback, so a forged notification cannot move money or unlock a subscription.

Application security

• The platform runs on a currently supported release of PHP and the Laravel framework, and we keep both on maintained versions so that upstream security patches remain available to us. We share exact version and patch levels with customers under a confidentiality agreement rather than publishing them here.
• Database access goes through an object-relational mapper that uses parameterised statements, which removes the ordinary route to SQL injection.
• Template output is escaped by default, which mitigates cross-site scripting.
• Cross-site request forgery protection is applied to web forms and to cookie-authenticated interactive requests.
• Input is validated by explicit request rules before it reaches business logic.
• Security headers are set on responses: X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and X-XSS-Protection.
• Trusted proxy handling is configured so that client IP addresses recorded in logs and used for rate limiting are accurate behind a load balancer.
• Dependencies are tracked through a lock file and updated as part of ordinary maintenance, with security advisories prioritised.

Audit logging and monitoring

• Each workspace has its own audit log recording the acting user, the action, the affected record, the previous and new values, and the originating IP address and browser string. Administrators can review it inside the Service.
• Platform-level administrative actions are recorded in separate landlord and platform audit logs, including organisation creation and deletion, data export and import, and support impersonation. Credential fields are redacted before an entry is written.
• High-volume machine-generated entries are pruned on a daily schedule so that the audit trail stays readable and useful during an investigation.
• Application logs are collected through configurable channels, and background jobs that fail are recorded for inspection and replay rather than being lost.
• Platform health is monitored continuously so that database, cache and queue problems are detected before they become customer-visible outages.

Backups and data portability

• A daily automated backup of platform-level data and an inventory of object storage runs on schedule, and backup jobs are tracked with their status and outcome.
• Administrators can generate a complete export of their workspace on demand, covering the modules on their plan together with custom fields, relationships and stored files. Download links expire after seven days, and a fresh export can be generated at any time.
• Before a workspace is ever deleted for non-payment, an export is generated automatically and 14 days' notice is given, as set out in our Terms of Service.
• Backups exist to recover the platform. They are not a substitute for your own retention practice, so we recommend taking periodic exports and storing them under your own control.

Data residency and sub-processors

Our Privacy Policy lists every sub-processor we rely on, what each receives, and the safeguards we apply when personal data moves outside Tanzania under Part V of the Personal Data Protection Act, 2022. Each sub-processor is engaged under a written contract requiring confidentiality, security measures at least as protective as our own, processing strictly on our instructions, and cooperation on data-subject requests and breach notification.

If you have data-residency obligations, contact us before you load regulated records so we can confirm the hosting arrangements that apply to your deployment in writing.

Incident response and breach notification

We maintain procedures to detect, triage, contain, eradicate and recover from security incidents, and to record what happened and what we changed afterwards. Our commitments:

• Where we are the data controller, we notify the Personal Data Protection Commission of a security breach affecting personal data without undue delay, as section 27(5) of the Personal Data Protection Act, 2022 requires.
• Where we process personal data on your behalf, we notify you without undue delay after becoming aware, and give you the facts you need to meet your own notification duty as controller.
• Our notification will describe what happened, which data and workspaces were affected, what we have done to contain it, what we recommend you do, and what we are changing to prevent recurrence.
• We will not delay telling you in order to complete an investigation. We report what we know, then follow up.

People and internal access

• Our staff hold individual named accounts. Shared logins are not used.
• Administrative permissions are granted on the basis of role and need, and are reviewed when a role changes or someone leaves.
• Production credentials are held in environment configuration, not in source code, documents or chat.
• Staff are bound by confidentiality obligations covering customer data.
• Access to a customer workspace follows the constrained, logged and visible process described above.

Assurance status and roadmap

Overstating security is a risk to you and to us, so we are direct about the formal assurances we do not currently hold. You should know this before a procurement decision rather than discover it during your own review.

• No SOC 2, ISO/IEC 27001 or comparable certification. We follow the practices on this page, but we have not completed an independent audit, and we will not claim a certification we do not hold.
• No published third-party penetration test report. We will share results with customers once we have commissioned one.
• No contractual uptime percentage on standard plans. Talk to us if you need a formal service-level agreement with availability targets and remedies.
• Automated per-workspace database backups delivered to storage you control are not yet a product. On-demand exports cover this need in the meantime, and the capability is on our roadmap.

We also maintain an internal register of known gaps in our technical controls, together with the compensating controls and the remediation timeline for each. We share that register, our detailed control-by-control responses, the configuration of your specific environment, and our version and patch levels directly with customers and prospects under a confidentiality agreement. We do not publish that detail here, because a public list of the precise weak points in a live platform is an invitation to attack it and would put our existing customers at risk.

If an assurance item you need is missing, ask us. We will tell you honestly where it sits in our plans, and we would rather lose a deal than misrepresent our posture to win one.

Your part of the shared responsibility

We secure the platform. You control who reaches your data inside it. Please:

• enable two-factor authentication, especially for every administrator;
• use strong, unique passwords and a password manager, and never share accounts between people;
• grant the narrowest role each colleague needs, and review roles when people change duties or leave;
• remove departed users promptly, and rotate any API key or integration they held;
• set an expiry date on workspace API keys, scope each key to the narrowest set of abilities it needs, and revoke keys and tokens you no longer use;
• review connected integrations periodically and revoke anything unused;
• run your own malware scanning on files you receive from outside your organisation before you circulate them, and treat ChapFlow storage as a business document store rather than an antivirus gateway;
• keep sensitive personal data out of free-text fields and notes unless you genuinely need it and have the required consent;
• restrict who can see employee records, attendance and performance data; and
• tell us at once at support@chapflow.com if you suspect unauthorised access.

Reporting a vulnerability

We welcome reports from security researchers, and we will not pursue legal action against anyone who reports a genuine issue in good faith and follows the guidance below.

Please email support@chapflow.com with:

• a clear description of the issue and its potential impact;
• the steps or proof of concept needed to reproduce it; and
• the affected URL or endpoint, and the time of your testing.

When testing, please do:

• use only accounts and workspaces you own or have written permission to test;
• stop as soon as you confirm a vulnerability, and access the minimum data needed to demonstrate it; and
• give us a reasonable opportunity to remediate before disclosing publicly.

Please do not:

• access, modify, exfiltrate or retain another customer's data;
• run denial-of-service, volumetric or spam testing, or attempt social engineering of our staff or customers; or
• use automated scanners at a rate that degrades service for others.

We aim to acknowledge a report within 2 business days, give an initial assessment within 10 business days, and keep you informed until it is resolved. We are happy to credit you when we publish a fix, if you would like that. Note that unauthorised access to a computer system is an offence under the Cybercrimes Act, 2015 of Tanzania, so please stay within the scope above.

Contact

• Security reports and questionnaires: support@chapflow.com
• Data protection and privacy: support@chapflow.com
• Operated by: The Site Weavers, Dar es Salaam, United Republic of Tanzania
• Company website: https://www.siteweavers.co.tz

Completing a vendor security questionnaire or reviewing us before a procurement decision? Write to us and we will answer it directly, including anything this page does not cover.