Security Overview

Effective date: 1 July 2026

Last updated: 1 July 2026

1. Introduction

Sales Day Software Ltd takes the security and protection of Customer information seriously.

This Security and Data Protection Overview explains the principal organisational, application and provider controls used to protect information processed through Sales Day.

It is intended to help Customers understand:

• how Sales Day is structured;
• how access to Customer Data is controlled;
• how Workspaces are separated;
• how third-party providers are used;
• how integrations and payments are protected;
• what Customers are responsible for;
• how incidents may be reported; and
• which security matters depend on Sales Day's underlying platform providers.

This document should be read together with the:

• Sales Day Terms of Service;
• Sales Day Privacy Notice;
• Sales Day Data Processing Addendum;
• Sales Day Acceptable Use Policy;
• Sales Day Cookie Notice; and
• Sales Day Subprocessor List.

2. About Sales Day

Sales Day is provided by:

Sales Day Software Ltd
Company number: NI740756

Registered office:

15 Kerrsland Drive
Belfast
BT5 6ER
United Kingdom

Security enquiries and reports should be sent to:

security@sales.day

Privacy enquiries should be sent to:

privacy@sales.day

General support enquiries should be sent to:

support@sales.day

3. Scope of this Overview

This Overview applies to the Sales Day websites, application and supporting operational processes.

It covers security relating to:

• User Accounts;
• personal Workspaces;
• Team Workspaces;
• Customer CRM data;
• Tasks and Meetings;
• billing;
• transactional email;
• calendar integrations;
• imports and exports;
• support;
• administrative access; and
• application operations.

This document is not:

• a penetration-test report;
• a formal certification;
• a service-level agreement;
• a guarantee that a security incident can never occur;
• a replacement for a Customer's own security assessment; or
• a representation that Sales Day itself holds every certification held by its providers.

4. Shared responsibility

Security is a shared responsibility between:

1. Sales Day;
2. Sales Day's platform and service providers;
3. Customers;
4. Workspace owners and administrators; and
5. individual Users.

4.1 Sales Day responsibilities

Sales Day is responsible for matters including:

• configuring application permissions;
• defining Workspace access rules;
• applying server-side authorisation checks;
• protecting administrative functions;
• managing integrations used by the Service;
• limiting access to operational need;
• handling Customer security reports;
• responding to incidents;
• selecting appropriate providers;
• maintaining contractual data-protection arrangements; and
• reviewing and correcting identified application issues.

4.2 Provider responsibilities

Underlying providers are responsible for controls within their own services, which may include:

• hosting;
• database security;
• authentication infrastructure;
• network security;
• encryption;
• infrastructure resilience;
• backups;
• payment processing;
• email delivery; and
• OAuth infrastructure.

4.3 Customer responsibilities

Customers are responsible for:

• protecting login credentials;
• using secure devices and networks;
• choosing suitable Workspace roles;
• removing Users who no longer require access;
• reviewing integrations;
• controlling exported files;
• entering data lawfully;
• limiting sensitive information;
• maintaining any additional backups they require;
• responding to suspicious activity; and
• reporting potential incidents promptly.

5. Security governance

Sales Day applies a practical, risk-based approach to security.

This currently includes:

• reviewing access-control rules;
• testing Workspace separation;
• auditing sensitive backend functions;
• reviewing Stripe webhook and billing logic;
• testing imports and exports;
• restricting platform-administrator functions;
• maintaining support and audit records;
• investigating reported defects;
• applying narrowly scoped corrections;
• reviewing third-party provider documentation; and
• updating security controls as the Service develops.

Sales Day does not currently represent that it operates a separately certified information-security management system.

6. Application architecture

Sales Day is delivered as a cloud-based web application.

The application uses Base44 as its principal application platform for services including:

• hosting;
• application execution;
• database services;
• User authentication;
• backend functions;
• application storage;
• routing; and
• supporting infrastructure.

Additional providers are used for specific functions, including:

• Stripe for payments and Subscriptions;
• Resend for transactional email; and
• Google for Customer-selected calendar integration.

Current providers are described in the Sales Day Subprocessor List.

7. Authentication

User authentication is provided through the underlying application platform.

Authentication controls support:

• Account registration;
• login;
• protected sessions;
• logout;
• authenticated application access;
• password-reset or recovery processes provided by the platform;
• invitation acceptance; and
• protected backend requests.

Sales Day does not store or require access to a User's plain-text password.

Certain authentication controls, password requirements, session behaviour and multi-factor-authentication availability depend on the underlying platform.

Sales Day does not currently claim that multi-factor authentication is mandatory or available to every User unless it is expressly shown in the application.

8. Account security

Users must not share individual Account credentials.

Customers should:

• use a unique password;
• protect access to the registered email Account;
• sign out of shared devices;
• review Workspace membership regularly;
• remove departed employees or contractors;
• avoid forwarding invitation links;
• monitor unusual Account activity; and
• contact Sales Day promptly if compromise is suspected.

Sales Day may temporarily restrict access where reasonably necessary to protect:

• the Customer;
• another User;
• Customer Data;
• the Service; or
• a third party.

9. Workspace isolation

Sales Day separates Customer Data using Workspaces.

Supported Workspace types include:

• personal Workspaces; and
• Team Workspaces.

Customer records are associated with a Workspace identifier.

Application and database-access rules are designed to ensure that ordinary Users may access only records belonging to a Workspace in which they have an authorised role.

Sales Day's access model includes:

• Workspace membership checks;
• active-Workspace checks;
• role-based permissions;
• database row-level security rules;
• server-side verification;
• protection against unauthorised client-supplied Workspace identifiers; and
• restrictions on administrative operations.

Personal Workspace data remains logically separate from Team Workspace data.

10. Role-based access

Team Workspaces may support roles such as:

• owner;
• administrator;
• manager; and
• member.

Available actions depend on the User's role and the feature involved.

Workspace owners and authorised administrators may be permitted to:

• invite Users;
• remove Users;
• change roles;
• manage seats;
• access Workspace records;
• configure Workspace settings;
• manage billing;
• export data; and
• perform other administrative actions.

Customers are responsible for assigning appropriate roles.

11. User removal

When a User is removed from a Team Workspace:

• their Team membership is removed;
• their access to Team records is revoked;
• their active Workspace is redirected where necessary;
• records created by them may remain part of the Team Workspace; and
• their separate personal Workspace is not automatically deleted.

Sales Day uses server-side controls to reduce the risk that a removed User retains access merely because a previous Workspace identifier remains stored in the client or User profile.

12. Database access controls

Sales Day uses database-level access rules and application-level checks.

These controls are intended to prevent unauthorised access based solely on:

• guessed record identifiers;
• manipulated browser requests;
• client-supplied Workspace values;
• altered URLs; or
• hidden application controls.

Database rules are used alongside backend authorisation rather than relying only on whether a button or page is visible.

Platform administrators may have broader access where required for support, security and operations.

13. Backend functions

Sensitive actions are implemented through authenticated backend functions where appropriate.

Backend functions may:

• authenticate the requesting User;
• determine the current Workspace;
• verify membership;
• verify role;
• reload authoritative records;
• reject unauthorised identifiers;
• enforce plan limits;
• validate input;
• log an operation; and
• use service-level access only after checks have completed.

Examples include functions supporting:

• billing;
• Team membership;
• data imports;
• record merging;
• calendar synchronisation;
• Subscription changes;
• data cleanup; and
• administrative support.

14. Administrative access

Sales Day maintains a platform-administrator role for legitimate operational purposes.

Platform-administrator access may be used for:

• customer support;
• security investigation;
• billing support;
• Workspace recovery;
• data cleanup;
• incident response;
• webhook troubleshooting;
• email or digest troubleshooting; and
• correcting operational problems.

Administrative access is not intended for unrelated review or exploitation of Customer Data.

Sales Day personnel and authorised contractors must access Customer Data only where reasonably necessary and subject to confidentiality obligations.

15. Provider-level security

Sales Day relies on the security controls operated by its platform and service providers.

Depending on the provider, these may include:

• infrastructure security;
• encryption in transit;
• encryption at rest;
• network controls;
• database protection;
• access logging;
• vulnerability management;
• backup and recovery measures;
• fraud prevention;
• payment-security controls;
• service monitoring; and
• independent assurance reports.

Provider-level controls remain subject to the provider's own documentation, contractual commitments and service architecture.

Sales Day will not describe itself as independently certified merely because one of its providers holds a certification.

16. Encryption

Sales Day relies on its providers for encryption of hosted and transmitted data.

Provider documentation may describe controls such as:

• encrypted HTTPS/TLS connections;
• encryption of hosted data;
• protected database services;
• encrypted payment environments; and
• protected provider credentials.

Sales Day does not currently claim:

• end-to-end encryption;
• Customer-controlled encryption keys;
• field-level encryption for every CRM field; or
• independent Sales Day key-management infrastructure.

Because the Service is not end-to-end encrypted, authorised provider personnel may technically be capable of accessing information where required for legitimate platform operations, support or security.

17. Secrets and credentials

Application secrets, provider credentials and sensitive integration values are stored through protected platform mechanisms rather than deliberately embedded in Customer-facing source code.

Protected secrets may include credentials used for:

• Stripe;
• Resend;
• Google integrations;
• internal administrative operations; and
• webhook verification.

Secret values must not be displayed to ordinary Users or included in public error messages.

18. Stripe and payment security

Sales Day uses Stripe for:

• checkout;
• Subscriptions;
• invoices;
• payment collection;
• payment recovery;
• Customer Portal access; and
• billing management.

Payment-card information is entered into Stripe-controlled systems.

Sales Day does not store full payment-card numbers or card-security codes.

Sales Day receives limited payment and Subscription information necessary to:

• identify the Customer;
• manage the Subscription;
• determine plan access;
• update billing status;
• manage seats;
• handle payment failure; and
• process cancellation or restart.

Stripe webhook messages are verified before Sales Day applies relevant Subscription changes.

19. Email security

Sales Day uses Resend for transactional email.

Transactional emails may include:

• Team invitations;
• support replies;
• record notifications;
• mentions;
• billing information;
• system notices; and
• Morning Digests.

Email delivery records may include:

• recipient;
• message type;
• delivery status;
• provider message identifier;
• attempt count;
• failure information; and
• sending time.

Customers should avoid placing unnecessary confidential or sensitive information in messages sent to external recipients.

Email transmission cannot guarantee that a recipient's inbox, device or mail provider is secure.

20. Morning Digest controls

Morning Digest preferences are stored against the User Account.

Users may select:

• whether the digest is enabled;
• delivery time;
• delivery days; and
• timezone.

Delivery processing includes mechanisms intended to:

• identify eligible Users;
• respect selected days;
• calculate local delivery time;
• scope content to the relevant Workspace;
• record delivery status; and
• prevent ordinary duplicate delivery for the same User and local date.

Users may disable the Morning Digest through Settings.

21. Google Calendar integration

Google Calendar integration uses OAuth authorisation.

A User must approve the relevant Google permissions before Sales Day can exchange calendar data.

Depending on the synchronisation feature used, Sales Day may:

• read relevant event information;
• create events;
• update events;
• delete events;
• store Google event identifiers;
• store synchronisation metadata; and
• associate calendar events with Sales Day Tasks or Meetings.

Calendar operations are scoped to the authenticated User and relevant Workspace.

Users may disconnect the integration through Sales Day or their Google Account.

Disconnecting may stop future synchronisation but may not automatically remove events already created in Google.

22. OAuth security

OAuth is used to avoid requiring Sales Day to collect a User's Google password.

OAuth tokens and connection credentials are handled through platform connector infrastructure.

Sales Day does not intentionally expose OAuth tokens through Customer-facing pages.

Users should disconnect integrations that are no longer required.

23. Import security

Sales Day supports CSV import for selected CRM entities.

Import controls include:

• authenticated access;
• role checks;
• Workspace validation;
• field mapping;
• input validation;
• relationship validation;
• pipeline-stage validation;
• duplicate handling;
• plan-capacity checks;
• server-side Workspace assignment;
• request tracking;
• result reporting; and
• idempotency protections.

Import requests must not be used to:

• introduce malware;
• exploit spreadsheet software;
• bypass plan limits;
• overwrite unrelated data;
• access another Workspace; or
• overload the Service.

24. Export security

Sales Day supports CSV export for supported CRM entities.

Export controls include:

• permission checks;
• Workspace scoping;
• paginated retrieval;
• lifecycle filtering;
• readable relationship resolution; and
• spreadsheet-formula-injection protection.

Authorised Users are responsible for protecting exported files after download.

Exports may contain confidential business or personal information and should not be:

• left on shared devices;
• emailed insecurely;
• uploaded to unauthorised services; or
• retained longer than necessary.

25. Spreadsheet-formula protection

CSV fields beginning with characters commonly interpreted as spreadsheet formulas may be prefixed or escaped before export.

This is intended to reduce the risk that opening a CSV in spreadsheet software automatically executes a malicious formula.

Customers should still exercise care when opening files imported from untrusted sources.

26. Input validation

Sales Day validates input where appropriate to the feature.

Validation may include:

• required fields;
• email formatting;
• date and time values;
• record relationships;
• permitted pipeline stages;
• numeric limits;
• plan restrictions;
• role restrictions;
• Workspace membership; and
• lifecycle state.

Validation reduces risk but does not remove the Customer's responsibility for data accuracy and lawful use.

27. Error handling

Sales Day uses controlled error messages intended to:

• inform Users when an operation fails;
• avoid exposing secrets;
• avoid exposing raw stack traces;
• prevent blank pages where possible; and
• provide a safe recovery route.

An application-content error boundary is used to reduce the risk that one page-level rendering error blanks the entire authenticated application.

The application shell and navigation should remain available where the failure is limited to the current page.

28. Logging and audit information

Sales Day maintains operational records for selected activities.

Depending on the feature, this may include:

• Team invitations;
• Team-member removal;
• administrative actions;
• Stripe webhooks;
• Subscription changes;
• support tickets;
• email delivery;
• Morning Digest delivery;
• import requests;
• failed operations;
• record lifecycle information; and
• security-relevant events.

Not every User action is necessarily captured in a comprehensive immutable audit log.

Sales Day does not currently claim to provide an enterprise-grade security information and event management system to Customers.

29. Duplicate and idempotency controls

Selected operations include mechanisms intended to reduce accidental duplication.

These may include:

• request identifiers;
• delivery keys;
• webhook-event identifiers;
• status records;
• processing locks;
• duplicate detection;
• retry checks; and
• completed-request replay protection.

No distributed system can guarantee that every rare failure mode is impossible.

Sales Day reviews high-risk duplicate scenarios where they could affect:

• billing;
• imports;
• notifications;
• calendar events; or
• Subscription changes.

30. Availability

Sales Day aims to provide a reliable Service.

Availability depends partly on:

• Base44;
• internet connectivity;
• third-party providers;
• Stripe;
• Resend;
• Google;
• DNS;
• browser operation;
• maintenance; and
• circumstances outside Sales Day's reasonable control.

Sales Day does not currently provide a guaranteed uptime commitment or formal service-level agreement unless separately agreed in writing.

31. Backups and recovery

Sales Day relies on its application and infrastructure providers for platform-level backup, resilience and recovery controls.

Sales Day does not currently promise:

• a fixed Customer-specific backup schedule;
• a fixed recovery-point objective;
• a fixed recovery-time objective;
• indefinite restoration;
• record-by-record restoration; or
• recovery of every deleted record.

Customers should use available export tools to maintain copies required for:

• business continuity;
• regulatory retention;
• internal backup;
• migration; or
• risk management.

32. Deletion

Users may be able to:

• archive records;
• soft-delete records;
• permanently delete records;
• remove Team members;
• delete eligible Workspaces; and
• request Account deletion.

Signing out does not delete data.

Subscription cancellation does not automatically delete an Account or Workspace.

Deleted information may remain temporarily in:

• backups;
• logs;
• billing records;
• security records;
• support records; or
• provider systems,

where required for legal, operational or recovery purposes.

33. Data minimisation

Customers should enter only information reasonably necessary for legitimate sales and customer-management purposes.

Sales Day discourages the unnecessary storage of:

• sensitive personal data;
• medical information;
• criminal-offence data;
• children's information;
• payment-card details;
• passwords;
• secret credentials;
• government identifiers; or
• unrelated private information.

Users should review free-text notes carefully because they may contain information not captured by structured controls.

34. Restricted data

Sales Day is not intended as a specialist platform for:

• health records;
• payment-card storage;
• classified information;
• critical infrastructure;
• biometric identification;
• criminal-justice records;
• large-scale children's data;
• safety-critical systems; or
• other highly regulated workloads requiring specialist contractual or technical controls.

Customers should contact privacy@sales.day before using Sales Day for a processing activity involving materially elevated data-protection risk.

35. Security testing and review

Sales Day may use a combination of:

• code review;
• provider security tools;
• access-control review;
• row-level-security review;
• controlled test Workspaces;
• billing rehearsals;
• permission tests;
• import and export rehearsals;
• mobile testing;
• error-handling tests;
• webhook verification;
• issue investigation; and
• remediation review.

Any temporary test functions, records or elevated permissions should be removed or restored after testing.

36. Vulnerability reporting

Security concerns should be reported privately to:

security@sales.day

A useful report should include:

• a description of the issue;
• affected page, function or record type;
• steps to reproduce;
• potential impact;
• screenshots or supporting evidence;
• the reporter's contact details; and
• whether any Customer Data may have been accessed.

Do not:

• access data beyond what is necessary to demonstrate the issue;
• modify or delete another person's data;
• disrupt the Service;
• use automated attacks that create excessive load;
• publish the vulnerability before Sales Day has had a reasonable opportunity to investigate; or
• demand payment through threats or coercion.

Sales Day will review good-faith reports and respond as reasonably practicable.

Sales Day does not currently operate a guaranteed bug-bounty programme.

37. Incident response

When Sales Day becomes aware of a potential security incident, it may:

1. assess the report;
2. preserve relevant records;
3. contain affected access or functionality;
4. involve the relevant provider;
5. investigate the cause and scope;
6. correct or mitigate the issue;
7. assess whether personal data is affected;
8. notify affected Customers where required;
9. notify a regulator or individual where legally required;
10. monitor for recurrence; and
11. document lessons and corrective actions.

Actions will depend on:

• severity;
• data involved;
• number of affected Users;
• ongoing risk;
• provider involvement;
• legal duties; and
• available evidence.

38. Personal-data breaches

Where Sales Day acts as a Processor and becomes aware of a confirmed Personal Data Breach affecting Customer Personal Data, it will notify the relevant Customer without undue delay in accordance with the Data Processing Addendum.

Where Sales Day acts as Controller, it will assess whether notification is required to:

• the Information Commissioner's Office;
• affected individuals; or
• another relevant authority.

Incident notification does not necessarily mean that Sales Day caused the incident or accepts liability.

39. Customer incident reporting

Customers should contact security@sales.day promptly if they become aware of:

• stolen credentials;
• unauthorised Workspace access;
• accidental disclosure;
• an exposed export file;
• malicious imported data;
• unusual billing activity;
• unauthorised integration access;
• a compromised email Account;
• a suspicious invitation;
• incorrect member access; or
• another event that may affect Sales Day security.

Prompt reporting can reduce harm and improve recovery.

40. Support access

Sales Day support may require limited access to:

• User details;
• Workspace information;
• record identifiers;
• Subscription information;
• error details;
• audit records; or
• affected Customer Data.

Support access should be limited to what is reasonably necessary to:

• diagnose the issue;
• verify authority;
• correct the issue;
• protect security; or
• comply with law.

Customers should avoid including unnecessary confidential or sensitive information in support tickets.

41. Customer exports and local security

After Customer Data is exported from Sales Day, the Customer controls that copy.

Customers should consider:

• encryption of stored exports;
• access permissions;
• secure file transfer;
• retention;
• deletion;
• secure backups;
• device protection; and
• whether recipients are authorised.

Sales Day cannot protect a file after it has been downloaded and transferred outside the Service.

42. Mobile and device security

Sales Day may be accessed through a mobile or desktop browser.

Users should:

• use supported and updated browsers;
• keep devices patched;
• use device passcodes;
• avoid untrusted public devices;
• sign out of shared devices;
• protect email Accounts;
• avoid storing exports unnecessarily; and
• report lost or compromised devices.

Sales Day is not responsible for malware or insecure configuration on a Customer-controlled device.

43. Third-party integrations

Integrations introduce a shared security boundary.

Customers are responsible for:

• reviewing permissions;
• authorising the correct Account;
• managing external administrators;
• revoking unused access;
• complying with provider terms;
• reviewing data created in the external service; and
• understanding that external copies may remain after disconnection.

Sales Day cannot control a third-party provider's independent security practices.

44. Service providers and subprocessors

Sales Day assesses and uses providers appropriate to the functions they perform.

Provider arrangements may include contractual requirements relating to:

• confidentiality;
• security;
• processing instructions;
• incident reporting;
• international transfers;
• deletion;
• downstream subprocessors; and
• assistance with data-protection obligations.

Current providers are listed in the Sales Day Subprocessor List.

45. International processing

Some providers may process or permit access to information outside the United Kingdom.

Sales Day uses contractual and legal safeguards where required, as explained in the:

• Privacy Notice;
• Data Processing Addendum; and
• Subprocessor List.

Security standards and legal protections can differ between countries.

46. Security limitations

No web application, cloud platform, integration or electronic communication method is completely secure.

Security may be affected by:

• software defects;
• zero-day vulnerabilities;
• compromised credentials;
• provider incidents;
• Customer misconfiguration;
• malicious insiders;
• insecure devices;
• email compromise;
• internet attacks;
• human error; or
• events beyond reasonable control.

Sales Day does not guarantee that:

• every attempted attack will be prevented;
• every message will be delivered securely;
• every deleted item can be restored;
• every incident will be detected immediately; or
• every provider will remain continuously available.

This does not reduce Sales Day's obligation to apply reasonable and appropriate measures.

47. Certifications and assurance

Sales Day does not currently claim that Sales Day Software Ltd itself is independently certified to:

• ISO 27001;
• ISO 27701;
• SOC 2;
• SOC 3;
• PCI DSS;
• Cyber Essentials; or
• another formal security standard.

Certain underlying providers may hold certifications or assurance reports.

Those provider certifications apply to the provider's audited systems and scope, not automatically to every aspect of Sales Day.

Relevant provider documentation may be made available directly by the provider or through its Trust Centre.

48. Future security development

Sales Day expects its security programme to develop as the Service and Customer base grow.

Potential future measures may include:

• formal incident-response documentation;
• expanded audit logging;
• stronger administrative monitoring;
• multi-factor authentication where supported;
• formal vulnerability testing;
• independent penetration testing;
• Cyber Essentials assessment;
• enhanced provider monitoring;
• Customer security questionnaires;
• formal retention schedules;
• continuity planning; and
• further security documentation.

The inclusion of a future measure in this section is not a commitment that it is currently available or will be delivered by a particular date.

49. Customer security checklist

Customers should, at minimum:

1. use individual User Accounts;
2. protect credentials;
3. review Team membership regularly;
4. assign the lowest appropriate role;
5. remove former staff promptly;
6. verify external email recipients;
7. review Google integration permissions;
8. keep devices and browsers updated;
9. protect downloaded exports;
10. minimise sensitive notes;
11. report suspicious activity;
12. maintain any required independent backups; and
13. ensure that their use of Sales Day complies with applicable law.

50. Contact

Security questions, vulnerability reports and suspected incidents should be sent to:

security@sales.day

Privacy questions should be sent to:

privacy@sales.day

General support requests should be sent to:

support@sales.day

Postal contact:

Sales Day Software Ltd
15 Kerrsland Drive
Belfast
BT5 6ER
United Kingdom

Company number: NI740756