A professional compliance and transparency guide for Octbe customers, prospects, partners, and internal teams.
This guide describes Octbe's GDPR readiness model for website visitors, prospective customers, subscribers, demo requesters, platform users, administrators, and business contacts. It is written as a practical privacy and compliance guide for customers, vendors, partners, and internal teams evaluating Octbe.
The guide is not legal advice and does not replace a signed Data Processing Agreement, contract terms, or advice from qualified counsel. It is designed to document the controls, operating principles, and customer-facing information that a responsible SaaS provider should maintain under the EU GDPR and related privacy expectations.
Octbe's approach is based on privacy by design, data minimisation, role-based access, encryption in transit, restricted service exposure, documented vendor review, data subject rights handling, and clear accountability for processing activities.
This document applies to the public Octbe website at octbe.com, demo/contact workflows, newsletter/subscriber workflows, support conversations, account access, analytics, security operations, and SaaS platform workflows that may process personal data or business contact data.
It covers operational guidance for EU/EEA GDPR, UK GDPR where relevant, and general international privacy best practice. Where country-specific legal requirements differ, the stricter or locally applicable rule should be assessed before processing begins.
For enterprise customers, Octbe should make customer-specific processing schedules, subprocessors, retention rules, security commitments, and incident notification terms available through a contract or DPA.
Octbe may act as a controller for data collected directly from website visitors, leads, subscribers, demo requesters, job/partner contacts, security reporters, and administrative account users where Octbe determines the purposes and means of processing.
Octbe may act as a processor when a customer uses the platform to upload, connect, analyse, or manage customer-controlled business data and Octbe processes that data only on the customer's documented instructions.
Customers remain responsible for ensuring they have a lawful basis to upload, connect, or process personal data inside Octbe. Octbe should support customers with processor commitments, security controls, audit information, and deletion/export assistance where applicable.
Lawfulness, fairness, and transparency: Octbe should explain what personal data is collected, why it is used, the lawful basis, retention period, recipients, rights, and contact channels in clear privacy information.
Purpose limitation: personal data should be collected for defined purposes such as account access, demo handling, support, security, billing, product operation, analytics, and communications. New purposes should be assessed before reuse.
Data minimisation: Octbe should collect only data that is necessary for a defined business or legal purpose. Optional fields should remain optional unless required for service delivery or compliance.
Accuracy: account and contact records should be kept reasonably accurate, with mechanisms for correction by the user or administrator.
Storage limitation: data should not be retained indefinitely. Each category should have a defined retention rule or review cadence.
Integrity and confidentiality: Octbe should protect personal data through technical and organisational measures appropriate to risk.
Website and lead data: name, email address, company, role, message content, consent status, IP address, browser/device metadata, and analytics events.
Account data: user ID, email, name, role, permissions, authentication metadata, access logs, profile settings, support communications, and security events.
Customer-controlled data: uploaded procurement data, supplier contact data, reporting data, contract metadata, spend records, operational comments, and customer-defined dashboard or workflow content.
Payment and commercial data: billing contact details, invoices, plan information, renewal status, commercial communications, and procurement documents where applicable.
Security data: logs, IP addresses, abuse indicators, audit trails, session metadata, rate-limit events, access control changes, and vulnerability reports.
Contract: used when processing is necessary to provide a requested service, create and operate user accounts, deliver support, administer subscriptions, or perform pre-contract demo and sales steps requested by a prospect.
Legitimate interests: may apply to website security, fraud prevention, service improvement, B2B communications, analytics with appropriate safeguards, and internal administration, provided Octbe balances those interests against individual rights and expectations.
Consent: should be used where required for optional marketing communications, non-essential cookies, certain newsletter subscriptions, and other processing where consent is the most appropriate basis. Consent should be specific, informed, freely given, and withdrawable.
Legal obligation: may apply to accounting, tax, compliance, regulatory requests, litigation hold, and legal record retention.
Vital interests and public task are unlikely to be routine bases for Octbe, but may be assessed if an exceptional circumstance arises.
Octbe's privacy notice should identify Octbe as the controller where applicable, provide contact details, describe processing purposes and lawful bases, list categories of personal data, identify recipients or categories of recipients, explain international transfers, define retention periods or criteria, and explain rights.
For data collected from forms, the privacy notice or form context should explain why information is requested and whether it is mandatory.
Where data is obtained indirectly, Octbe should provide Article 14-style information unless an exception applies.
Octbe should maintain a documented workflow for access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and rights related to solely automated decision-making where applicable.
Requests should be logged with date received, requester identity verification steps, scope, responsible owner, action taken, response date, and any reason for refusal or limitation.
GDPR requests generally require response without undue delay and within one month, subject to limited extensions for complex requests. Processors should assist controllers with customer data rights requests where required by the DPA.
Octbe should not delete data needed for legal obligations, security investigation, billing records, or legitimate dispute handling unless legally appropriate.
Network exposure: databases, Redis, administrative services, SSH, and application backends should not be publicly exposed unless there is a documented, hardened business need. Access should be restricted by firewall, VPN, private network, or Cloudflare/Tunnel-style controls.
Access control: administrative access should be limited by least privilege, strong authentication, unique accounts, and regular permission review.
Secrets management: secrets must not be committed to Git, embedded in public files, or stored in plaintext backups without protection. Exposed credentials should be rotated promptly.
Logging and monitoring: authentication logs, application errors, WAF/security events, and privileged actions should be monitored. Logs should be protected from unauthorised access and retained only as needed.
Encryption and backup: backups should be encrypted or access-restricted, tested periodically, and stored separately from the live system. Restore procedures should be documented.
Change management: security-impacting changes should be tracked, tested, and reviewed before production where feasible.
Confidentiality: personnel and contractors with access to personal data should be bound by confidentiality obligations.
Training: administrators and support personnel should receive privacy and security training appropriate to their role.
Need-to-know access: user, support, billing, and technical data should be available only to people who need it for a defined role.
Vendor review: subprocessors and service providers should be assessed for security, privacy commitments, data location, retention, and incident notification.
Policy review: this guide, privacy notices, subprocessors, and retention schedules should be reviewed at least annually or after material changes.
When Octbe acts as a processor, processing should occur only on documented customer instructions, unless legally required otherwise.
Personnel with access to customer personal data should be subject to confidentiality obligations.
Octbe should implement appropriate technical and organisational security measures under GDPR Article 32 principles.
Octbe should support customer obligations for data subject rights, DPIAs, security of processing, breach notification, deletion, return, and audit information as agreed in a DPA.
Subprocessors should be used only under suitable contractual commitments and, where required, with notice to or authorisation from the customer.
Octbe should keep an internal subprocessor register identifying service name, purpose, data categories, location or transfer mechanism, security documentation, contract/DPA status, and review date.
Vendors used for hosting, email, analytics, security, support, backups, and payment processing should be reviewed before use and periodically thereafter.
Where personal data leaves the EEA/UK or is accessed internationally, transfer safeguards such as adequacy, Standard Contractual Clauses, UK IDTA/addendum, or other legally appropriate mechanisms should be assessed.
Before transferring personal data outside the EEA/UK, Octbe should identify the destination, recipient, transfer tool, supplementary measures, and residual risk.
Where Standard Contractual Clauses or equivalent mechanisms are used, Octbe should maintain documentation and assess whether recipient country risks require supplementary safeguards.
Customer contracts should identify transfer mechanisms where Octbe acts as processor.
Website enquiries should be retained only as long as needed for sales, support, security, audit, or legal purposes.
Newsletter data should be retained until unsubscribe, consent withdrawal, inactivity-based deletion, or account deletion where appropriate.
Account records should be retained during active service and then archived or deleted according to contract, legal, billing, and security requirements.
Customer-controlled data should be exportable and deletable according to customer instructions, contractual terms, and technical feasibility.
Backups should follow a defined retention cycle and should not become a hidden permanent copy of deleted data.
A personal data breach is a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
Octbe should maintain an incident response process covering detection, containment, assessment, evidence preservation, risk evaluation, notification decisions, remediation, and lessons learned.
Where Octbe is a controller and a breach is likely to result in risk to individuals, supervisory authority notification may be required within 72 hours after becoming aware, unless an exception applies. High-risk breaches may require communication to affected individuals.
Where Octbe is a processor, it should notify the relevant customer controller without undue delay after becoming aware of a personal data breach affecting customer data.
A Data Protection Impact Assessment should be considered before processing likely to result in high risk, such as systematic monitoring, large-scale processing of sensitive data, extensive profiling, or combining datasets in ways that create significant risk.
For procurement analytics, a DPIA may be appropriate if customer data includes identifiable employees, supplier contacts, performance scoring, behavioural monitoring, special category data, or automated decisions with significant effects.
DPIA records should describe the processing, necessity and proportionality, risks to individuals, mitigations, residual risk, and review date.
Octbe should distinguish strictly necessary cookies from analytics, marketing, and preference cookies.
Non-essential cookies or similar technologies should be disclosed and, where required, used only after valid consent.
Analytics should be configured with privacy-friendly settings where feasible, including IP masking or minimisation, limited retention, and restricted sharing.
Cookie consent records should document consent state, timestamp, preference category, and withdrawal mechanism where required.
If Octbe provides AI-assisted analysis, summaries, categorisation, or recommendations, it should document the processing purpose, data inputs, model/provider involvement, human review model, and whether outputs create legal or similarly significant effects.
Customer-facing AI features should avoid unnecessary personal data, use role-based controls, and make clear when outputs are suggestions rather than final decisions.
If automated decision-making with legal or similarly significant effects is introduced, additional GDPR Article 22-style safeguards and transparency should be assessed before launch.
Customers should ensure they have a lawful basis for personal data uploaded into Octbe and should provide appropriate privacy information to their own employees, suppliers, contractors, and business contacts.
Customers should configure access permissions appropriately, avoid uploading unnecessary sensitive data, review user accounts regularly, and define retention or deletion rules for their own datasets.
Customers should notify Octbe if they require a DPA, specific subprocessor information, export assistance, deletion assistance, or security documentation.
Maintain an up-to-date privacy notice and cookie notice.
Keep a record of processing activities for controller and processor operations.
Maintain a data map and retention schedule.
Review access permissions and admin accounts regularly.
Keep databases and internal services off the public internet.
Rotate secrets after exposure and avoid committing secrets to Git.
Maintain vendor/subprocessor records and DPAs.
Test backups and restoration procedures.
Log data subject rights requests and respond within the required timeframe.
Review this guide after product, vendor, infrastructure, or legal changes.
Important note: This document is a governance and transparency guide. It is not legal advice, a certification, or a guarantee of compliance in every customer context.
This guide was prepared using current public guidance from reputable privacy authorities and GDPR educational resources. Official regulator guidance should be checked before relying on this document for legal or regulatory decisions.
| Source | Topic | URL |
|---|---|---|
| European Data Protection Board | SME Data Protection Guide: Respect individuals' rights | https://www.edpb.europa.eu/sme-data-protection-guide/respect-individuals-rights_en |
| ICO | Lawfulness, fairness and transparency principle | https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/lawfulness-fairness-and-transparency/ |
| ICO | Guide to lawful basis | https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/ |
| GDPR.eu | Data Processing Agreement overview and template | https://gdpr.eu/data-processing-agreement/ |
| GDPR.eu | Guide to GDPR data privacy requirements | https://gdpr.eu/data-privacy/ |