Security & Trust

Customer traffic on the SMSBite platform carries authentication codes, account notifications and personal data belonging to our customers’ own users. The controls set out on this page are the technical and organisational measures we operate to protect it, and they are written to be read as commitments: each one describes something in place today, in enough detail that a security reviewer can test it against what they find.

We complete customer security questionnaires and vendor assessments as part of procurement, and supporting documentation — architecture description, data-flow diagrams and control evidence — is provided to prospective and contracted customers under non‑disclosure. Send questionnaires and specific control requirements to security@smsbite.com.

One boundary worth stating precisely: the controls on this page protect the platform and the data it holds. They are separate from message delivery to a handset, which crosses operator networks outside our control and is governed by the SLA.

• In transit. All API and web traffic between customer systems and SMSBite endpoints is encrypted using TLS 1.2 or higher, with TLS 1.3 preferred where the client supports it. Legacy protocol versions and export-grade or otherwise obsolete cipher suites are disabled.
• Cipher suites. We configure modern authenticated-encryption cipher suites with forward secrecy, and review the configuration when recommendations change.
• HSTS. HTTP Strict Transport Security is enabled on our web and API hosts so that compliant clients will not downgrade to cleartext.
• At rest.Data at rest — including databases, object storage and backups — is encrypted using AES-256.
• Key management. Encryption keys are held in a managed key-management service, access to key material is restricted to the service accounts that require it, and keys are rotated on a defined schedule and additionally on demand following any suspected exposure. Key material is not stored in source code, configuration repositories or ticketing systems.

Traffic between SMSBite and upstream aggregator or operator partners uses the strongest transport protection each interconnect supports, negotiated per partner at the point the interconnect is established and reviewed when it is renewed.

Access to production systems and to customer data is granted on a least-privilege basis: a person receives the narrowest set of permissions that allows them to do their job, and no more.

• Multi-factor authentication is required for all administrative access to production systems and to the management consoles of our infrastructure providers.
• Every administrator holds a unique named account. Shared or generic logins are not used, so that every administrative action is attributable to an individual.
• Privileges are assigned by role rather than ad hoc, and elevated permissions are separated from day-to-day working accounts.
• Access rights are reviewed periodically, and entitlements that are no longer justified by a current role are removed.
• Access is revoked promptly on a change of role and on departure, as part of a defined offboarding step rather than at the discretion of the individual.

• API keys are issued per account, and separate keys can be issued for separate environments or integrations so that a single compromised key does not expose everything.
• Keys can be rotated at any time and revoked immediately. A revoked key stops working without waiting for an expiry window.
• Keys are scoped to the operations the integration actually needs.
• Credentials are not written to application logs in plaintext. Where a credential appears in a request, it is redacted before the request is recorded.
• IP allow-listing is available on supported account plans; ask during onboarding whether it applies to yours. Where it is enabled, API use is restricted to the source addresses you nominate.

Guidance for customers. Store API keys server-side, in a secret manager or equivalent protected configuration store. Never embed a key in a mobile application, a single-page web application, browser JavaScript, a public repository or any other artefact that an end-user can inspect — a key distributed to a client device must be treated as already public. Send from your own backend, rotate keys on a schedule and on staff changes, and use distinct keys for testing and production. If you believe a key has been exposed, revoke it and notify security@smsbite.com.

• Production and staging environments are segregated. Staging does not share credentials with production, and production customer data is not used for development or testing.
• Administrative access to infrastructure is restricted to controlled network paths rather than being exposed to the open internet.
• Firewall and security-group rules follow a default-deny posture: only the ports and protocols required for the service are reachable, and internal services are not publicly addressable.
• Hosts are built from hardened, minimal images with unnecessary services removed.
• Patch management follows a defined cadence, with routine operating-system and dependency patching on a regular cycle and out-of-cycle patching for vulnerabilities we assess as critical or actively exploited.
• DDoS mitigation is applied at the network edge by our infrastructure and edge providers, together with rate limiting on public endpoints.

• Changes to application code are peer-reviewed before they are merged. Direct pushes to protected branches are not permitted.
• Static analysis runs in the build pipeline, and findings above the agreed severity threshold block a release until they are resolved or explicitly accepted with a recorded justification.
• Third-party dependencies are scanned for known vulnerabilities, and advisories affecting components we use are triaged and remediated in line with their severity.
• Services ship with secure defaults: authentication required by default, transport encryption on by default, and no debug or verbose diagnostic modes enabled in production.
• Input received at API boundaries is validated and normalised, and parameterised queries and output encoding are used to prevent injection.
• Secrets are supplied to applications through configuration and secret management rather than being committed to source control.

• Authentication events, API access and administrative actions against production systems are logged, including the acting identity, the source address and the time.
• Security and audit logs are retained for twenty-four (24) months, in line with the retention schedule in our Privacy Policy, unless a longer period is required by law or by an open investigation.
• Automated alerting is configured for anomalous access patterns — repeated authentication failures, administrative action outside expected patterns, access from unexpected sources and sudden changes in traffic shape — and alerts are routed to the on-call engineer.
• Security and audit logs are held separately from customer message content. Operational logging records message metadata and delivery state; it is not a store of message bodies, and access to message content is separately restricted.
• Logs are protected against casual modification, and access to them is itself restricted and recorded.

SMSBite maintains a documented incident response procedure. Platform and security telemetry is monitored continuously by automated detection, which pages an on-call engineer through a rotation that covers every hour of the year. The procedure is rehearsed, and the escalation path is defined before it is needed rather than during an incident.

The procedure defines severity levels, so that the response is proportionate and the escalation path is known in advance:

• Critical— confirmed or strongly suspected unauthorised access to customer data, or a full platform outage. Immediate escalation, including to management.
• High— significant degradation, or a vulnerability that is exploitable in production.
• Medium and low — contained issues and defects handled through the normal remediation cycle.

Response follows defined stages: triage and severity assignment; containment, including credential revocation and isolation of affected components; eradication of the root cause; recovery and verification that the service is operating correctly; and a post-incident review that records what happened and what changes follow from it.

Notification to customers. Where an incident materially affects a customer’s data or service, we notify the affected customer without undue delay, with the information available at the time and updates as the investigation progresses.

Notification to authorities. In respect of end-recipient personal data routed through the platform, the customer is the controller and SMSBite is the processor. Under Article 33 of the GDPR, it is the controller that must notify the competent supervisory authority of a qualifying personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. SMSBite’s corresponding obligation as processor is to notify the customer without undue delay after becoming aware of a personal data breach, and to provide the assistance the customer reasonably needs to meet its own notification duties. Where SMSBite acts as controller in its own right — for example in respect of account-holder data — we notify the competent supervisory authority ourselves where the law requires it.

• Production data is backed up on a regular schedule, and backups are retained for a defined period before expiry.
• Backups are encrypted at rest using AES-256, and access to backup storage is restricted in the same way as access to production.
• Restores are tested periodically. A backup that has never been restored is not a backup, so restore exercises are a scheduled activity rather than something first attempted during an incident.
• Platform components are deployed redundantly, and routing is configured across more than one aggregator partner for supported destinations, so that the failure of a single upstream partner does not by itself stop message submission.

The availability target that applies to the API and platform control plane, and the operator-side conditions that govern delivery to a handset, are set out in the SLA.

Controller and processor roles, the categories of data we process, retention periods, sub-processors and the safeguards applied to international transfers are set out in full in the Privacy Policy. This page does not restate them.

In summary: retention of message content is minimised. We hold message content only for as long as it is needed to submit, route and account for the message and to meet operator, regulatory and dispute-resolution requirements; delivery metadata is retained longer than content for reconciliation and reporting.

The Data Processing Addendum is issued with and forms part of every Order Form, covering SMSBite’s processing of personal data on the customer’s instructions. It is not issued on request only. Requests for a copy of the DPA, the current sub-processor list or transfer documentation should go to privacy@smsbite.com.

• Personnel and contractors with access to systems or data are bound by written confidentiality obligations, which continue after the engagement ends.
• Personnel are expected to be familiar with our security policies, including credential handling, device protection, phishing awareness and the obligation to report a suspected incident promptly rather than attempt to resolve it quietly.
• Onboarding grants least-privilege access appropriate to the role, requested and recorded rather than copied from another person’s account.
• Offboarding revokes access to production systems, consoles and shared services promptly on departure, and access is re-scoped on a change of role.

Security of the overall messaging flow is shared. SMSBite is responsible for the platform, its infrastructure and the controls described above. The customer is responsible for everything on its own side of the API, including:

• Securing its API credentials — storing them server-side, restricting who can read them, rotating them and revoking them when staff or integrations change.
• Securing the systems and endpoints from which it calls the API, including operating-system patching, workstation security and access control over its own dashboard users.
• Securing its webhook receivers — serving them over TLS, validating that a callback genuinely originates from SMSBite, and treating callback payloads as untrusted input rather than executing them.
• Protecting the recipient data it uploads or submits, and holding a lawful basis and demonstrable opt-in for every recipient it messages.
• Configuring and honouring opt-out handling, including processing STOP and equivalent keywords, maintaining suppression lists and ensuring that a recipient who opts out is not messaged again.
• Notifying SMSBite promptly at security@smsbite.com if it suspects that a credential, sender ID or account has been compromised.

Content and traffic obligations are set out in the Acceptable Use Policy and the Anti-Spam Policy.

If you believe you have found a security vulnerability in the SMSBite platform, please report it to security@smsbite.com. We would rather hear from you than not.

Please include a description of the issue and its likely impact, the affected endpoint, host or component, the steps needed to reproduce it, any request or response evidence, the date and time of your testing, and how you would like to be contacted.

Rules of engagement. Please do not test against production systems without our prior written authorisation, and never send test traffic to real recipients — messages sent to live handsets cause harm to uninvolved people and may breach operator rules. Do not run automated scanning that degrades the service, do not attempt denial-of-service or social engineering of our personnel or partners, do not access, modify or delete data belonging to anyone else, and stop as soon as you have enough to demonstrate the issue. Please give us a reasonable opportunity to remediate before any public disclosure.

Acknowledgement. We aim to acknowledge a report sent to security@smsbite.com within five (5) business days. This is a target response window, not a resolution time. Once we have triaged the report we will give you an assessment and an indicative remediation timeline.

Safe harbour. If you make a good-faith effort to comply with the rules of engagement above, we will treat your research as authorised conduct, will not pursue or support legal action against you in relation to it, and will work with you to understand and resolve the issue. If a third party brings action against you for research conducted in compliance with this policy, we will make clear that it was authorised. This safe harbour does not extend to testing that breaches the rules above, in particular testing against production without authorisation or against real recipients.

Recognition. This is a coordinated disclosure programme rather than a paid bounty programme. Researchers who report a valid issue are credited by name in our advisory if they wish to be, and are told when the fix ships.

Security reports, security questionnaires and questions about the measures on this page:

Related documents: Privacy Policy, Terms of Service, Acceptable Use Policy and the SLA.