SECURITY OVERVIEW

Last updated: 20 June 2026
Effective from: 20 June 2026
Version: 1.0

1. About This Overview

This Security Overview explains the high-level security approach used for NibbleKit platform services operated by Paul Hepple, a sole trader trading as DarkByte Creations.

In this overview, DarkByte, NibbleKit, we, us and our refer to Paul Hepple trading as DarkByte Creations.

This overview applies to NibbleKit services that link to it, including, where applicable:

• mobile and web applications;
• public websites;
• Customer accounts;
• Merchant and administration portals;
• ordering and checkout workflows;
• verification and password-reset services;
• payment and refund tooling;
• support and privacy-request services;
• notification services;
• APIs;
• demo or trial workspaces; and
• supporting platform systems.

This is a public summary. It does not disclose security-sensitive implementation details and does not replace:

• DarkByte's internal security policies;
• incident-response procedures;
• business-continuity plans;
• the Merchant agreement;
• the data-processing agreement;
• a Merchant security schedule; or
• provider-specific security obligations.

2. Security Responsibilities

Security responsibilities depend on the relevant service and processing role.

DarkByte is responsible for security measures applying to:

• NibbleKit platform technology operated by DarkByte;
• DarkByte-controlled accounts and administrative access;
• software and configuration changes made by DarkByte;
• DarkByte-selected service providers;
• DarkByte's own devices and operational processes;
• personal data for which DarkByte is controller; and
• processor security obligations accepted under a Merchant data-processing agreement.

A Merchant is responsible for:

• determining who may use its Merchant account;
• assigning appropriate roles;
• removing access promptly;
• protecting Merchant-managed devices and networks;
• securing information exported from NibbleKit;
• maintaining accurate staff contact information;
• controlling Merchant-selected integrations;
• responding to security incidents within the Merchant's own organisation;
• complying with its controller obligations; and
• securing any systems outside NibbleKit that the Merchant connects to or operates.

Customers are responsible for:

• protecting their own credentials;
• securing devices used to access the service;
• using accurate account and contact details;
• reviewing security messages; and
• reporting suspected account compromise promptly.

The existence of responsibilities for a Merchant or Customer does not remove security obligations applying directly to DarkByte.

3. Security Principles

DarkByte's security programme is based on the following principles:

• access should be limited to authorised people and purposes;
• users should receive only the permissions reasonably required;
• personal data should be collected and retained only where needed;
• security should be considered during design and change;
• systems should be maintained and monitored proportionately to risk;
• security events should be recorded and investigated;
• vulnerabilities should be reported through a clear route;
• incidents should be contained and learned from;
• service providers should be assessed before and during use;
• backups should support recovery without creating indefinite retention; and
• security claims should reflect actual implemented controls.

Security controls are selected by reference to:

• the nature of the service;
• the sensitivity of the data;
• the number and type of users;
• foreseeable threats;
• potential consequences;
• legal and contractual requirements; and
• the cost and availability of appropriate safeguards.

4. Information-Security Governance

DarkByte maintains documented processes proportionate to the size and risk of the NibbleKit service.

These processes cover, as applicable:

• security ownership;
• access approval;
• privileged access;
• staff and contractor confidentiality;
• change management;
• vulnerability handling;
• provider review;
• backup and recovery;
• incident response;
• personal-data breach assessment;
• record retention;
• legal holds;
• Merchant notifications; and
• post-incident review.

Security responsibilities must be assigned to identifiable people rather than left to informal or assumed ownership.

Material security policies and procedures are reviewed:

• periodically;
• following a material platform change;
• following a significant incident;
• where a new category of sensitive data is introduced;
• where a material provider changes; or
• where law or contractual obligations change.

5. Identity and Access Management

Access to non-public NibbleKit functions is controlled through authentication and authorisation measures appropriate to the role and risk.

Controls include, where applicable:

• unique user accounts;
• role-based access;
• least-privilege permissions;
• separation of Customer, Merchant and privileged functions;
• account verification;
• session expiry;
• credential revocation;
• multifactor authentication;
• access logging;
• periodic access review;
• prompt staff offboarding; and
• additional controls for privileged access.

DarkByte personnel and contractors may access production systems or personal data only where:

• the access is authorised;
• there is a legitimate operational purpose;
• the level of access is appropriate;
• confidentiality obligations apply; and
• relevant activity is capable of review.

Shared privileged credentials must not be used merely for convenience.

Where an emergency-access process is used, access must be:

• limited;
• recorded;
• reviewed after use; and
• revoked when the emergency ends.

6. Passwords, Credentials and Sessions

NibbleKit is designed not to store ordinary account passwords in readable plain text.

Credentials must be protected using measures appropriate to their type.

Users must not:

• disclose passwords or one-time codes;
• reuse another person's account;
• share Merchant User accounts;
• store credentials in an insecure shared document;
• send credentials through ordinary support messages; or
• enter credentials into a page or app they do not trust.

DarkByte may:

• revoke active sessions;
• require a password reset;
• require additional verification;
• block a compromised token;
• restrict an account; or
• disable access

where compromise or misuse is reasonably suspected.

Password-reset and verification links must:

• expire;
• be single-purpose;
• be invalidated after successful use where technically appropriate; and
• be transmitted through an approved channel.

7. Encryption and Data Transmission

Authentication, payment and personal-data communications over public networks must use appropriately protected transport.

DarkByte uses encrypted network transport for supported NibbleKit web, app and API connections involving personal or confidential information.

Users must not intentionally bypass security warnings or transmit sensitive information through an unapproved insecure route.

Encryption at rest or equivalent access protection is applied where appropriate to:

• production databases;
• backups;
• secrets;
• credentials;
• provider configuration;
• portable exports; and
• other sensitive records.

Encryption is one safeguard and does not replace:

• access control;
• data minimisation;
• monitoring;
• secure deletion; or
• incident response.

Cryptographic keys, secrets and service credentials must be:

• restricted;
• stored separately from ordinary application content where appropriate;
• rotated when compromise is suspected;
• removed when no longer needed; and
• excluded from public source code and ordinary support records.

8. Data Minimisation and Separation

NibbleKit security measures include limiting the amount and location of sensitive information.

DarkByte seeks to:

• avoid collecting unnecessary personal data;
• avoid storing full payment credentials;
• separate reusable allergy profiles from longer-lived financial metadata;
• restrict free-text fields from being used for inappropriate sensitive information;
• limit exports;
• restrict access by Merchant and role;
• keep demo data separate from approved production use;
• apply defined retention periods; and
• delete or anonymise information when it is no longer needed.

Customer, Merchant and administrative data must not be mixed merely for convenience where separation is reasonably required.

A user's access to one Merchant does not permit access to another Merchant's data.

9. Secure Development and Change Management

Security is considered when NibbleKit software, configuration and infrastructure are created or changed.

Depending on the nature and risk of the change, controls may include:

• documented requirements;
• peer or independent review;
• automated checks;
• dependency review;
• access-control testing;
• validation of data-processing changes;
• payment-flow testing;
• test and production separation;
• approval before deployment;
• rollback planning;
• monitoring after release; and
• security assessment before enabling a material new integration.

Security-sensitive changes include changes affecting:

• authentication;
• authorisation;
• Merchant separation;
• payment or refund flows;
• personal data;
• allergy information;
• account deletion;
• data exports;
• external integrations;
• secrets;
• logging; or
• privileged administration.

Live personal data must not be used for ordinary development or demonstration where synthetic or appropriately anonymised information is sufficient.

A production change must not be made through an unauthorised personal account or unreviewed local workaround.

10. Dependency and Vulnerability Management

DarkByte maintains processes for identifying, assessing and addressing vulnerabilities in:

• NibbleKit code;
• software dependencies;
• supported operating environments;
• provider configurations;
• authentication and authorisation rules;
• APIs;
• public pages;
• mobile applications; and
• Merchant administration functions.

Vulnerabilities are prioritised by considering:

• exploitability;
• affected data and users;
• privilege required;
• exposure;
• available mitigations;
• evidence of active exploitation;
• provider guidance; and
• potential business or safety consequences.

A material vulnerability may result in:

• a security update;
• temporary feature restriction;
• credential rotation;
• provider configuration change;
• Merchant notification;
• forced session revocation;
• additional monitoring; or
• another proportionate safeguard.

Security updates should be installed within a period appropriate to the risk.

DarkByte does not promise that every vulnerability can be remedied immediately. Urgent risks will be mitigated or contained while a durable correction is prepared where immediate complete remediation is not reasonably possible.

11. Logging, Monitoring and Detection

NibbleKit may record security-relevant events such as:

• successful and failed authentication;
• account verification;
• password resets;
• privileged access;
• role changes;
• order or refund actions;
• unusual traffic;
• access-control failures;
• security warnings;
• provider events;
• administrative changes; and
• suspected abuse.

Logs are used for purposes such as:

• investigating account compromise;
• detecting fraud;
• diagnosing faults;
• establishing incident timelines;
• supporting Merchants;
• demonstrating authorised activity; and
• meeting legal or contractual obligations.

Logging must be proportionate.

Logs must not intentionally contain:

• plain-text passwords;
• card security codes;
• complete payment credentials;
• unnecessary health information; or
• secrets that should be stored elsewhere.

Access to logs is restricted according to role and need.

Security logs are retained in accordance with the Data Retention and Deletion Policy.

12. Backup, Recovery and Resilience

DarkByte maintains backup and recovery arrangements proportionate to the NibbleKit services and data involved.

Measures may include:

• scheduled backups;
• access restrictions;
• separation from ordinary production access;
• recovery procedures;
• restoration testing;
• provider resilience;
• documented dependencies;
• monitoring; and
• incident communication.

Backups are intended for resilience and disaster recovery. They are not used to retain data indefinitely or to avoid deletion obligations.

Backup retention and deletion are described in the Data Retention and Deletion Policy.

Where intentionally deleted personal data is restored during disaster recovery, applicable deletion and suppression instructions must be reapplied within:

a reasonable period after restoration once restored data has been identified

No recovery arrangement guarantees that a service will be uninterrupted or that every item of recently changed data can always be restored.

13. Service Providers and Subprocessors

NibbleKit relies on third-party providers for functions that may include:

• hosting;
• storage;
• authentication;
• messaging;
• payments;
• diagnostics;
• security;
• mapping;
• notifications;
• customer support; and
• app distribution.

Before using a material provider, DarkByte considers matters such as:

• the service supplied;
• data involved;
• access required;
• security information;
• contractual protections;
• incident-notification terms;
• deletion and return;
• subprocessor use;
• international transfers;
• service resilience; and
• available assurance information.

Where a provider acts as processor, the applicable contract must impose data-protection and security obligations appropriate to the service.

A provider may act as an independent controller for some activities, such as regulated payment or app-store operations.

A provider's independent responsibility does not remove DarkByte's obligations concerning:

• provider selection;
• configuration;
• instructions;
• integration security;
• disclosure;
• monitoring; or
• processor management.

A current material-provider or subprocessor list is available at:

available from privacy@darkbyte.uk on request until a public material-provider register is published

14. Payment Security

Payments may be processed through:

Stripe Connect for card payments and supported wallet methods, plus any cash or offline payment option expressly enabled by the Merchant.

NibbleKit is designed so that full payment card numbers and card security codes are entered into or handled by approved payment-provider components rather than stored by DarkByte.

This payment-security statement reflects the current NibbleKit payment architecture and must be reviewed before any new web, mobile, Merchant or manual-payment flow is enabled.

DarkByte may retain limited payment-related information such as:

• payment-provider transaction identifiers;
• Merchant connected-account identifiers;
• amount and currency;
• payment status;
• payment method category;
• limited card metadata supplied by the provider;
• refund status;
• chargeback or dispute status;
• fraud signals; and
• receipt references.

DarkByte does not publish or imply a particular payment-security certification unless that certification has been independently verified and remains current.

Merchants and users must not enter:

• full card numbers;
• card security codes;
• payment-account passwords;
• bank login credentials; or
• wallet authentication codes

into menu content, order notes, support forms, privacy forms, screenshots or other ordinary NibbleKit fields.

A Merchant must not ask a Customer to send payment credentials by email, chat or telephone merely because a payment has failed.

Payment-provider outages or controls do not remove the Merchant's or DarkByte's responsibility for securely configuring and operating the parts of the payment workflow they control.

15. Merchant and Merchant User Security Responsibilities

A Merchant must ensure that only authorised people access its NibbleKit workspace.

The Merchant and its authorised users must:

• use individual accounts;
• keep staff identity and contact information current;
• assign the least level of access reasonably required;
• review access periodically;
• remove access promptly when a person changes role or leaves;
• use multifactor authentication where available or required;
• protect devices with appropriate access controls;
• keep operating systems and browsers reasonably current;
• avoid using untrusted public devices;
• lock unattended devices;
• protect downloaded reports and exports;
• use approved communication and storage systems;
• report suspected compromise promptly;
• cooperate with incident investigation;
• preserve relevant evidence;
• review unusual refund, order or account activity;
• prevent unauthorised access to Customer allergy information;
• obtain approval before connecting an external integration; and
• comply with the Merchant agreement and security schedule.

Merchant Users must not:

• share accounts;
• allow a colleague to act under their identity;
• copy Customer data to a personal account;
• use Customer information for curiosity or an unrelated purpose;
• store exports indefinitely;
• send Customer data to an unapproved AI service;
• disable a security control without authority;
• create an unauthorised backdoor or shared administrator account; or
• use live Customer data in a demo or test workspace.

The Merchant remains responsible for the security of information after it exports or copies that information from NibbleKit.

These responsibilities must be mirrored in the Merchant agreement or associated security schedule.

16. Customer Security Responsibilities

Customers should:

• use a strong password not shared with another person;
• protect access to their email account and device;
• keep recovery information current;
• sign out on a shared device;
• review unexpected security or order messages;
• avoid following suspicious links;
• use only an official or Merchant-authorised NibbleKit service;
• report unexpected account activity promptly; and
• avoid sending passwords or full payment-card information to support.

A Customer should contact support promptly where:

• they receive an unexpected verification or reset message;
• an unknown order appears;
• account details change unexpectedly;
• a device is lost while signed in;
• a login may have been compromised; or
• a payment appears unauthorised.

Customer responsibilities do not excuse a security failure caused by DarkByte or a Merchant.

17. Demo, Test and Trial Security

A service identified as a demo, preview, development, test or trial workspace is not approved for live use unless DarkByte expressly confirms otherwise.

Users must not enter:

• real Customer details;
• live orders;
• payment-card information;
• real allergy or health information;
• staff identity documents;
• confidential business records;
• production credentials; or
• information that must be retained as an official record

into a demo or test workspace.

Demo data may be:

• fictional;
• incomplete;
• reset;
• modified; or
• deleted without notice.

If real personal or confidential data is entered into a demo environment:

• the incident must be reported promptly;
• access may be restricted;
• the data may be removed;
• the security and privacy implications will be assessed; and
• the relevant Merchant may be notified.

18. Reporting Suspicious Activity or Data Exposure

Report suspected:

• account compromise;
• unauthorised access;
• exposed personal data;
• malicious activity;
• fraudulent orders;
• unauthorised refunds;
• leaked credentials;
• suspicious Merchant access;
• phishing using NibbleKit branding; or
• another active security concern

to:

Security email: support@nibblekit.com with the subject line Security report Support email: support@nibblekit.com Secure reporting form: No separate secure form is currently published; use support@nibblekit.com with the subject line Security report.

Include, where possible:

• the affected app, site or Merchant;
• the date and time;
• what you observed;
• relevant order or account reference;
• affected device or browser;
• screenshots with unnecessary personal data redacted; and
• steps already taken.

Do not send:

• passwords;
• one-time codes;
• full card details;
• card security codes;
• complete identity documents;
• another person's unrestricted personal data; or
• unnecessary health information

through ordinary email.

Where there is an immediate threat to life or physical safety, contact the appropriate emergency service rather than relying on the security mailbox.

19. Coordinated Vulnerability Disclosure

DarkByte welcomes good-faith reports of security vulnerabilities affecting NibbleKit-controlled systems.

This section explains:

• which assets may be tested;
• permitted research boundaries;
• prohibited activity;
• how to submit a report; and
• how DarkByte will handle coordinated disclosure.

This is not a bug-bounty programme.

No payment, reward, employment or commercial engagement is promised unless DarkByte agrees otherwise in writing before the relevant work.

20. Vulnerability-Disclosure Scope

Research is in scope only for:

• NibbleKit assets expressly listed at the NibbleKit-controlled services and domains that link to this policy;
• NibbleKit public domains expressly operated by DarkByte;
• NibbleKit mobile applications for which DarkByte or the confirmed App publisher has authorised testing under this policy; and
• a test account or test workspace lawfully created by the researcher.

The following are out of scope unless DarkByte gives prior written authorisation:

• Merchant-owned websites or systems outside NibbleKit;
• third-party payment-provider systems;
• Apple, Google or another app-store system;
• cloud-provider management systems;
• messaging or email-provider systems;
• staff or contractor personal devices;
• Merchant networks;
• delivery-provider systems;
• social-media accounts;
• physical premises; and
• any asset not controlled by DarkByte.

A reference or integration with a third-party provider does not authorise testing of that provider.

If you are unsure whether an asset is in scope, submit the information already available and do not continue testing until you receive written confirmation.

21. Permitted Good-Faith Research

Research under this policy must:

• be intended to identify and report a genuine security vulnerability;
• use only accounts and data that you own or are authorised to use;
• use synthetic test data wherever possible;
• be limited to the minimum activity needed to confirm the issue;
• avoid disrupting ordinary users;
• avoid accessing another person's information;
• stop immediately if personal, payment, health or confidential information is encountered;
• preserve the confidentiality of the report;
• avoid retaining data obtained unintentionally;
• remove any local copy of unintentionally accessed data after DarkByte confirms that preservation is not required;
• comply with reasonable instructions from DarkByte; and
• be reported promptly through the designated route.

Where a vulnerability can be demonstrated without exploitation, do not exploit it.

Where a limited proof of concept is necessary, it must not:

• change live data;
• create persistence;
• increase privileges beyond the minimum needed to demonstrate the issue;
• move laterally into another system;
• affect another account; or
• impair availability.

22. Prohibited Security Testing

You must not carry out:

• denial-of-service or distributed denial-of-service testing;
• load testing likely to affect availability;
• destructive testing;
• malware deployment;
• ransomware simulation against live systems;
• data destruction or alteration;
• deletion of accounts or orders that are not your own test records;
• credential stuffing;
• password spraying;
• brute-force authentication;
• phishing;
• social engineering;
• impersonation of DarkByte, a Merchant or a user;
• physical intrusion;
• attacks against staff devices;
• testing of third-party providers;
• live payment-card testing;
• unauthorised refunds or chargebacks;
• fraudulent orders;
• spam;
• high-volume automated scanning without written approval;
• supply-chain compromise;
• creation of persistent access or backdoors;
• exfiltration of personal or confidential information;
• publication before coordinated disclosure; or
• threats, extortion or demands for payment.

Do not access another user's account or data to prove that access is possible.

A vulnerability affecting another account should be demonstrated using:

• two accounts that you control;
• synthetic identifiers;
• a non-invasive request; or
• another method agreed with DarkByte.

23. Vulnerability Report Contents

A useful report should include:

• the affected asset;
• app or software version;
• vulnerability type;
• date and time identified;
• steps to reproduce;
• expected and actual behaviour;
• likely effect;
• prerequisites;
• proof-of-concept material;
• relevant request and response details with secrets redacted;
• suggested mitigation, where known;
• whether any personal data was encountered;
• whether exploitation appears active; and
• your preferred contact details.

Do not include:

• a live user's personal data;
• payment credentials;
• active session tokens;
• reusable secrets; or
• unnecessary database content.

Where a secret is necessary to identify the issue, redact it and offer to provide it through the secure route.

Reports should be sent to:

support@nibblekit.com with the subject line Security report

Encrypted reporting is available through:

No public PGP key is currently published; use the security email route unless DarkByte publishes a key later.

A security.txt file is available at:

No public security.txt route is currently published; use the security email route unless DarkByte publishes one later.

24. How We Handle Vulnerability Reports

When DarkByte receives an apparently valid report, we will aim to:

• acknowledge receipt within five business days;
• assign an internal reference;
• confirm whether the reported asset is in scope;
• carry out an initial triage within ten business days;
• assess severity and likely impact;
• ask proportionate follow-up questions;
• keep the reporter informed at reasonable intervals;
• investigate and remediate according to risk;
• coordinate any public disclosure; and
• confirm when the report is closed.

An acknowledgement does not confirm that:

• the issue is valid;
• it is in scope;
• it is unique;
• a reward will be paid; or
• a particular remediation date applies.

Remediation time depends on:

• severity;
• active exploitation;
• affected users;
• provider dependencies;
• testing requirements;
• availability of a safe mitigation; and
• the risk created by the correction itself.

Where immediate full remediation is not possible, DarkByte may apply a temporary mitigation.

25. Coordinated Public Disclosure

Do not publicly disclose a vulnerability, proof of concept or sensitive remediation information before:

• DarkByte confirms that the issue has been addressed;
• DarkByte and the reporter agree a disclosure date; or
• the coordinated-disclosure period described below has ended without a reasonable agreement.

The standard target for coordinated disclosure is:

90 calendar days from acknowledgement unless a different coordinated disclosure timeline is agreed

The period may be:

• shortened where there is active exploitation or an urgent public-safety need;
• extended where a third-party dependency or complex correction reasonably requires it; or
• changed by agreement.

DarkByte will not unreasonably withhold agreement to a responsible disclosure once users are appropriately protected.

Public credit may be provided where:

• the report was made in accordance with this policy;
• the reporter wants to be named;
• publication does not create a material security risk; and
• applicable confidentiality or legal restrictions permit it.

26. Good-Faith Research Assurance

To the extent that DarkByte has authority over the relevant asset, research conducted in good faith and in substantial compliance with this policy will be treated by DarkByte as authorised for the limited purpose of identifying and reporting a vulnerability.

Where those conditions are met, DarkByte will not initiate civil proceedings solely because the researcher carried out that authorised activity or submitted the report.

This assurance does not:

• authorise conduct outside the stated scope;
• authorise access to another person's data;
• authorise unlawful conduct;
• prevent DarkByte from acting where the researcher causes harm or acts dishonestly;
• bind a Merchant, provider, app store or other third party;
• bind law-enforcement or regulatory authorities; or
• provide immunity from generally applicable law.

Where a researcher becomes aware that they may have exceeded the scope unintentionally, they should:

• stop immediately;
• report what occurred;
• avoid further access;
• preserve only the minimum information needed to explain the event; and
• follow DarkByte's reasonable containment instructions.

27. Security Incident Response

A security incident is an event that may affect the confidentiality, integrity or availability of NibbleKit systems, information or services.

When DarkByte identifies or receives a credible report of a security incident, DarkByte will take steps appropriate to the circumstances, which may include:

• recording the event;
• assigning responsibility;
• preserving evidence;
• containing access;
• revoking credentials or sessions;
• restricting a feature;
• checking affected systems;
• applying a correction or mitigation;
• restoring service;
• assessing personal-data consequences;
• notifying affected Merchants;
• notifying providers;
• communicating with affected users;
• reporting to a regulator or authority;
• monitoring for recurrence; and
• completing a post-incident review.

DarkByte may prioritise containment and protection before providing a detailed public explanation.

Incident records are retained in accordance with the Data Retention and Deletion Policy.

28. Personal-Data Breaches

A personal-data breach is a security breach leading to the accidental or unlawful:

• destruction;
• loss;
• alteration;
• unauthorised disclosure of; or
• access to

personal data.

Not every security incident is a personal-data breach, and not every personal-data breach must be reported publicly or to the Information Commissioner's Office.

28.1 Where DarkByte is controller

Where DarkByte is controller, it will:

• record and assess the breach;
• evaluate the likelihood and severity of risks to individuals;
• document the decision whether notification is required;
• notify the Information Commissioner's Office without undue delay and, where required, no later than 72 hours after becoming aware;
• explain any report made later than the applicable period;
• provide information in phases where permitted and necessary; and
• inform affected individuals without undue delay where the breach is likely to result in a high risk and no applicable exception removes that requirement.

28.2 Where DarkByte is processor

Where DarkByte is processor for a Merchant, DarkByte will:

• notify the relevant Merchant without undue delay after becoming aware of a personal-data breach;
• provide information reasonably available about the nature and likely effect;
• provide updates as the investigation develops;
• assist with containment and evidence;
• assist the Merchant with risk assessment and required notifications;
• preserve relevant records; and
• follow lawful and documented Merchant instructions.

The Merchant remains responsible for deciding whether it must notify:

• the Information Commissioner's Office;
• affected individuals;
• another regulator; or
• another party,

unless DarkByte separately has its own controller notification obligation.

28.3 Breach records

DarkByte will document personal-data breaches, including those not reported to the Information Commissioner's Office.

The record will include, as appropriate:

• what happened;
• when DarkByte became aware;
• affected data and people;
• likely consequences;
• containment;
• remedial action;
• notification decisions;
• notifications made; and
• lessons or preventative action.

29. Merchant Incident Responsibilities

A Merchant must notify DarkByte promptly where an incident may affect:

• a NibbleKit Merchant account;
• NibbleKit credentials;
• Customer data obtained through NibbleKit;
• an export from NibbleKit;
• a Merchant-controlled integration;
• a payment or refund workflow;
• Merchant User permissions;
• Customer allergy information;
• a connected device or browser session; or
• the security of another NibbleKit user.

The Merchant must provide information reasonably needed to investigate, including:

• date and time;
• affected users;
• affected systems;
• suspected cause;
• actions taken;
• records preserved;
• whether personal data is involved; and
• the Merchant's incident contact.

The Merchant must not:

• conceal an incident;
• delete relevant evidence;
• contact affected Customers using misleading information;
• make a regulatory statement on DarkByte's behalf without authority; or
• delay notification merely because the full facts are not yet known.

DarkByte's processor-notification and assistance commitments, and the Merchant's incident duties, must be included in the Merchant data-processing agreement and security schedule.

30. Security Communications

DarkByte may communicate about an incident through:

• in-app notice;
• email;
• direct Merchant contact;
• support message;
• public service notice;
• telephone;
• provider status update; or
• another appropriate channel.

The content and timing will depend on:

• the risk;
• legal duties;
• active investigation;
• the need to avoid increasing exposure;
• the information currently known; and
• the relevant controller or processor role.

A security communication may be updated as facts change.

DarkByte will not knowingly make a materially misleading statement about:

• the nature of the incident;
• affected data;
• containment;
• responsibility; or
• required user action.

31. Law-Enforcement and Regulatory Cooperation

DarkByte may preserve or disclose security information where reasonably necessary and lawful to:

• respond to a court order;
• comply with a legal obligation;
• report suspected criminal conduct;
• protect a person from serious harm;
• cooperate with the Information Commissioner's Office;
• respond to another competent regulator; or
• establish, exercise or defend legal claims.

Requests for information will be assessed for:

• apparent authority;
• scope;
• necessity;
• proportionality;
• confidentiality;
• jurisdiction; and
• applicable data-protection requirements.

DarkByte will not provide unrestricted system or Customer access merely because a third party requests it informally.

32. No Absolute Security Guarantee

No internet, software, cloud or payment service can be guaranteed completely secure or continuously available.

This overview does not warrant that:

• every attempted attack will be prevented;
• every vulnerability will be identified before exploitation;
• every incident will be detected immediately;
• service will never be interrupted; or
• every item of data can be recovered after every event.

DarkByte nevertheless remains responsible for applying security measures appropriate to the risks and for meeting obligations that cannot lawfully be excluded.

A reference to shared responsibility does not transfer DarkByte's own obligations to a Customer or Merchant.

33. Security Questions, Privacy Requests and Ordinary Support

Use the vulnerability-disclosure route for a technical vulnerability.

Use the incident-reporting route for:

• suspected account compromise;
• exposed credentials;
• active unauthorised access;
• payment abuse;
• phishing; or
• another operational security incident.

Use the Privacy Rights and Data Protection Complaints page for:

• a privacy right;
• a data-protection complaint;
• a question about personal data;
• an account-deletion request; or
• concern about DarkByte's privacy handling.

Use ordinary Merchant support for:

• a product;
• delivery;
• collection;
• refund;
• food-safety; or
• order-service issue

that does not involve a security concern.

34. Changes to This Overview

We may update this overview to reflect changes in:

• law;
• NibbleKit functions;
• security practice;
• provider arrangements;
• vulnerability-disclosure processes;
• incident handling; or
• Merchant obligations.

The current version will show its last-updated date and version number.

A material change to Merchant security obligations will be handled through the applicable Merchant agreement or security schedule and will not be imposed solely through an unnotified public-page change where contractual agreement is required.

Previous material versions will be available at:

Previous material versions are available on reasonable request from support@nibblekit.com.

The security.txt expiry date and contact information will be reviewed at least:

every six months

35. Related Policies

This overview should link to:

• Privacy Policy
• Privacy Rights and Data Protection Complaints
• Data Retention and Deletion Policy
• Cookies and Similar Technologies Policy
• Acceptable Use Policy
• Terms and Conditions
• End User Licence Agreement
• Current Subprocessor List
• Vulnerability Disclosure Scope

36. Security and Support Contacts

NibbleKit is operated by:

Paul Hepple, a sole trader trading as DarkByte Creations 152 Lindhurst Road, Barnsley, S71 3DG

Security incidents:

support@nibblekit.com with the subject line Security report

Vulnerability reports:

support@nibblekit.com with the subject line Security report

Encrypted reporting:

No public PGP key is currently published; use the security email route unless DarkByte publishes a key later.

Ordinary platform support:

support@nibblekit.com

Privacy rights and data-protection complaints:

privacy@darkbyte.uk

Telephone:

07549 253991