Cookie & Storage Technologies Policy

THE RIGHT GUY LTD

COOKIE & STORAGE TECHNOLOGIES POLICY — VERSION 2

Effective date: [to be inserted on publication]

Last updated: 4 October 2026

This Policy explains how The Right Guy Ltd uses cookies and other technologies that store information on, or access information from, a user's device when using The Right Guy website and related services.

It should be read together with our Privacy Policy.

***

1. ABOUT THE RIGHT GUY

The Right Guy is operated by:

The Right Guy Ltd

Company number: 16425623

Registered office: 3rd Floor, 86–90 Paul Street, London, EC2A 4NE, United Kingdom

VAT number: 495353361

ICO registration number: ZB924668

In this Policy, "The Right Guy", "TRG", "we", "us" and "our" mean The Right Guy Ltd.

***

2. PURPOSE OF THIS POLICY

This Policy explains:

• what cookies and similar technologies are;
• which types of technology TRG may use;
• why we use them;
• when consent is required;
• when a legal exception may apply;
• how users can control optional technologies;
• how third-party technologies are treated; and
• how TRG maintains its technology inventory.

***

3. THIS POLICY COVERS MORE THAN COOKIES

The applicable rules are not limited to traditional browser cookies.

They can also apply to technologies that store information on or access information from a user's device, including:

• cookies;
• local storage;
• session storage;
• tracking pixels;
• scripts;
• tags;
• software development technologies;
• device identifiers;
• link-tracking technologies;
• fingerprinting technologies; and
• similar storage or access mechanisms.

We refer to these collectively in this Policy as Storage and Access Technologies or SATs.

***

4. WHAT IS A COOKIE?

A cookie is a small piece of information stored on a device when a website is used.

Cookies can perform functions such as:

• keeping a user logged in;
• maintaining security;
• remembering settings;
• supporting payments;
• remembering choices;
• preventing abuse;
• measuring website usage; or
• enabling other requested functionality.

***

5. FIRST-PARTY AND THIRD-PARTY TECHNOLOGIES

A first-party technology is generally operated in connection with The Right Guy's own website or domain.

A third-party technology may be provided by another organisation whose technology is integrated into TRG.

Third-party involvement does not automatically determine whether consent is required.

The purpose and operation of the technology must be considered.

***

6. SESSION AND PERSISTENT TECHNOLOGIES

Some technologies last only for a browser session.

Others remain for a defined period or until removed.

The appropriate duration depends on the purpose for which the technology is used.

TRG should not retain device information for longer than reasonably necessary for the relevant purpose.

***

7. THE BASIC RULE

Where applicable law requires consent before information is stored on or accessed from a user's device, TRG must obtain valid consent before the relevant technology operates.

TRG will not treat continued browsing alone as consent.

***

8. STORAGE AND ACCESS EXCEPTIONS

Applicable UK law provides limited circumstances in which consent may not be required.

Depending on the technology and purpose, these may include:

• transmission of communications;
• strictly necessary technologies;
• qualifying statistical-purpose technologies;
• qualifying appearance/functionality technologies; and
• other applicable statutory exceptions.

An exception applies only where its legal requirements are actually satisfied.

***

9. STRICTLY NECESSARY TECHNOLOGIES

A technology may be used without consent where it is genuinely necessary to provide an online service specifically requested by the user and the applicable legal requirements are satisfied.

Examples may include technologies necessary for:

• authentication;
• maintaining a logged-in session;
• account security;
• preventing security attacks;
• maintaining a checkout process;
• processing a requested payment;
• preserving a user's requested service state; or
• providing another service that could not reasonably operate without the technology.

***

10. NECESSARY MEANS NECESSARY

A technology is not strictly necessary merely because:

• it is useful to TRG;
• it improves our commercial performance;
• it provides interesting statistics;
• it is convenient;
• a plugin sets it by default; or
• a third-party supplier recommends it.

TRG assesses necessity from the perspective of providing the service requested by the user.

***

11. STATISTICAL-PURPOSE TECHNOLOGIES

UK law may permit qualifying technologies to be used without prior consent where their sole purpose is collecting statistical information about use of the service with a view to improving it and all applicable statutory conditions are satisfied.

Where TRG relies on this exception:

• the use must remain within the statutory statistical purpose;
• appropriate information must be provided;
• users must have a simple and free means of objecting; and
• the information must not also be used for an incompatible purpose such as advertising or behavioural targeting.

***

12. APPEARANCE AND FUNCTIONALITY PREFERENCES

UK law may also permit qualifying technologies used solely to adapt how the service appears or functions according to a user's preference, subject to the applicable conditions.

Where this exception is relied upon, TRG must provide appropriate information and a simple and free way to object.

***

13. MULTIPLE PURPOSES

A technology may perform more than one function.

If one purpose qualifies for an exception but another purpose requires consent, TRG must not treat the whole technology as exempt merely because one purpose qualifies.

The actual purposes must be assessed.

***

14. OUR TECHNOLOGY CATEGORIES

TRG may classify technologies into categories such as:

Essential / Strictly Necessary

Required for requested services, security, authentication or similar essential functionality.

Preferences / Functionality

Used to remember or provide user-selected functionality or presentation.

Analytics / Statistics

Used to understand website usage and improve TRG.

Advertising / Targeting

Used to create advertising audiences, track users for advertising or measure targeted advertising.

A technology's classification depends on its actual purpose and configuration.

***

15. WORDPRESS TECHNOLOGIES

The Right Guy operates using WordPress infrastructure.

WordPress may use technologies required for functions such as:

• authentication;
• login sessions;
• administration;
• security;
• account functionality; and
• user preferences.

Where these technologies are genuinely necessary to provide functionality requested by a logged-in user, they may fall within the strictly necessary exception.

***

16. WORDPRESS AUTHENTICATION COOKIES

When a user signs in, WordPress may use authentication cookies to recognise the authenticated session.

These may include dynamically generated WordPress authentication cookie names.

Provider: The Right Guy / WordPress

Purpose: authentication and logged-in session management

Category: Essential

Consent position: ordinarily no consent where strictly necessary for requested login/account functionality

Duration: according to the applicable WordPress session/login configuration

***

17. WORDPRESS SECURE AUTHENTICATION

WordPress may use secure authentication technologies in connection with protected administrative or account areas.

Purpose: security and authentication

Category: Essential

Consent position: ordinarily no consent where strictly necessary

***

18. WORDPRESS LOGGED-IN STATE

WordPress may use a technology to recognise that a user is logged in and determine the appropriate account experience.

Purpose: logged-in functionality

Category: Essential

Consent position: ordinarily no consent where strictly necessary

Duration: according to the applicable login/session configuration

***

19. WORDPRESS TEST COOKIE

WordPress may use a test cookie during login to determine whether the browser accepts cookies.

Purpose: login functionality/technical compatibility

Category: Essential where used as part of requested authentication

Duration: normally short/session based

***

20. USERSWP

TRG uses UsersWP functionality for user/account features.

The code audit confirms that UsersWP can use browser storage in connection with user-list display preferences.

***

21. USERSWP DIRECTORY VIEW PREFERENCE

UsersWP uses browser localStorage to remember a user's selected list/display view.

Technology: localStorage

Provider: The Right Guy / UsersWP

Purpose: remember the user's selected directory/list presentation

Category: Preference / Functionality

Duration: persistent until cleared or replaced by the browser/application

Consent/exception position: may qualify for the statutory appearance/functionality exception where all applicable requirements are satisfied, including appropriate information and a simple means of objecting

This technology should not be classified as advertising merely because it persists between visits.

***

22. MEMBERSHIP FUNCTIONALITY

TRG uses membership functionality in connection with Provider accounts.

Technologies genuinely required to:

• identify the authenticated Provider;
• establish membership entitlement;
• maintain account access; or
• provide a requested membership function

may be treated as essential where the statutory requirements are satisfied.

Membership status stored in TRG's server-side database is not itself necessarily a cookie or device-storage technology.

***

23. GETPAID AND PAYMENT FUNCTIONALITY

TRG uses payment functionality including GetPaid-related components.

Payment technologies may be required to:

• initiate checkout;
• process payment;
• prevent fraud;
• confirm transaction status;
• or maintain the requested payment process.

Their classification depends on their actual purpose.

***

24. STRIPE

Booking V2 and other applicable payment functionality may use Stripe payment infrastructure.

The code audit confirms that the Stripe integration loads Stripe.js from Stripe's infrastructure when applicable payment functionality is used.

Stripe may use Storage and Access Technologies as part of:

• payment processing;
• checkout;
• fraud prevention;
• authentication;
• security; and
• related payment functionality.

***

25. STRIPE TECHNOLOGIES ARE NOT AUTOMATICALLY ALL ESSENTIAL

TRG will not state that every technology associated with Stripe is automatically strictly necessary.

A Stripe technology must be assessed according to:

• the particular Stripe functionality used;
• its purpose;
• whether the user requested the relevant payment service;
• whether the technology is genuinely necessary; and
• applicable law.

Technologies used for unrelated analytics, advertising or other optional purposes require separate assessment.

***

26. BOOKING V2

Booking V2 itself primarily stores Booking, payment, legal and transaction records on TRG's server/database.

A server-side Booking record is not automatically a browser cookie.

Where Booking V2 uses browser storage or third-party device-access technology, that technology must nevertheless be assessed under this Policy.

***

27. BOOKING PAYMENT SECURITY

Technologies genuinely necessary to:

• securely initiate a Booking payment;
• prevent payment fraud;
• authenticate the payment;
• protect payment information; or
• complete a requested Booking transaction

may qualify as strictly necessary where the legal requirements are satisfied.

***

28. WORDfENCE SECURITY

TRG uses Wordfence functionality for website and login security.

Security technologies may be used in connection with:

• attack prevention;
• firewall functionality;
• login protection;
• authentication;
• abuse prevention;
• security monitoring; and
• protecting accounts.

***

29. SECURITY TECHNOLOGIES

Security-related Storage and Access Technologies may qualify as strictly necessary where they are genuinely necessary and proportionate to provide the requested service securely or to comply with applicable security obligations.

TRG will not classify unrelated tracking as security merely because it is supplied by a security plugin.

***

30. WPDISCUZ

The installed plugin set contains wpDiscuz functionality.

The code audit identifies several possible Storage and Access Technologies associated with this plugin.

Their publication and operation depend on whether the relevant wpDiscuz functionality is enabled and used on TRG.

***

31. COMMENT DRAFT STORAGE

wpDiscuz code uses browser sessionStorage for comment-draft functionality.

Where this functionality is active:

Technology: sessionStorage

Purpose: temporarily preserve a comment draft during the browser session

Category: Functionality

Duration: browser session

Consent/exception position: assess according to whether the functionality qualifies for an applicable exception

***

32. COMMENTER INFORMATION COOKIES

WordPress/wpDiscuz functionality can use cookies relating to commenter information where the user chooses applicable comment-cookie functionality.

These can include dynamically generated cookies associated with:

• comment author;
• comment email; and
• comment website.

They must not be listed as active on every TRG page merely because the plugin contains support for them.

***

33. WPDISCUZ SOCIAL LOGIN

The wpDiscuz code also contains functionality for a temporary social-login message cookie.

This does not establish that TRG currently offers wpDiscuz social login.

If that feature is activated, its technology must be included in the active inventory and assessed according to its actual purpose.

***

34. WP ROCKET

TRG uses WP Rocket for website performance/caching functionality.

WP Rocket contains compatibility code for numerous third-party plugins and cookies.

The presence of those names inside WP Rocket does not mean TRG actually uses those technologies.

TRG therefore does not publish every technology referenced in WP Rocket's compatibility code as though it were active.

***

35. WP ROCKET ADMIN STORAGE

WP Rocket code contains browser local-storage functionality used within administrative interfaces.

Technologies confined to TRG administrators are still subject to appropriate security and privacy consideration but are not necessarily technologies encountered by ordinary public visitors.

***

36. CONTACT FORMS

TRG uses contact-form functionality.

Submitting information through a form ordinarily creates server-side processing of the submitted information.

That fact alone does not mean the form uses an optional tracking cookie.

Any Storage and Access Technology added to a form by security, CAPTCHA, analytics or another integration must be assessed separately.

***

37. CAPTCHA AND ANTI-SPAM

Installed software may contain support for CAPTCHA or anti-spam integrations.

The existence of integration code does not establish that a particular CAPTCHA service is currently enabled.

If TRG activates a third-party CAPTCHA or equivalent technology, its scripts, device access and data transfers must be assessed and this Policy/inventory updated where necessary.

***

38. GOOGLE MAPS AND LOCATION FUNCTIONALITY

TRG may use Google Maps or Google Places functionality where enabled for location-related features.

Loading third-party map/location scripts may cause information to be communicated to or processed by the third-party provider.

These technologies must be assessed according to their actual configuration and purpose.

They are not automatically classified as strictly necessary merely because location functionality exists somewhere on the platform.

***

39. MAPS SHOULD BE LOADED PROPORTIONATELY

Where map/location functionality is not necessary on a particular page, TRG should avoid unnecessary third-party loading where reasonably practicable.

Where optional third-party map functionality requires consent, it should not be activated before the required choice.

***

40. EXTERNAL FONTS AND CONTENT DELIVERY NETWORKS

The TRG website may retrieve website resources such as fonts, icons, JavaScript or stylesheets from external infrastructure.

An external network request is not automatically an advertising cookie.

However, third-party requests may involve transmission of technical information such as an IP address and must be considered as part of TRG's privacy and technology architecture.

Where reasonably practical, TRG may reduce unnecessary third-party requests.

***

41. ANALYTICS

TRG may operate its own server-side analytics relating to platform activity.

A database record showing that a page, Provider or feature was used is not automatically a cookie or Storage and Access Technology.

The device-access rules apply where information is actually stored on or accessed from the user's device.

***

42. FIRST-PARTY STATISTICS

If TRG introduces or uses first-party device technologies solely for qualifying statistical purposes, TRG may rely on the applicable statutory statistical-purpose exception only where every condition is satisfied.

This includes providing:

• clear and comprehensive information; and
• a simple and free means of objecting.

***

43. STATISTICS MUST NOT BECOME ADVERTISING TRACKING

Information collected under a statistical-purpose exception must not silently be repurposed for:

• behavioural advertising;
• cross-site tracking;
• advertising audience creation;
• personalised marketing;
• or another incompatible purpose.

If a different purpose requires consent, consent must be obtained.

***

44. ADVERTISING AND TARGETING

At the date of this Policy, TRG does not classify any technology as exempt merely because it supports advertising revenue.

If TRG introduces:

• advertising cookies;
• remarketing pixels;
• cross-site tracking;
• behavioural advertising;
• advertising audience technologies; or
• similar targeting technologies,

they must not operate before valid consent where consent is required.

***

45. NO IMPLIED ADVERTISING CONSENT

A user does not consent to advertising or targeting technologies merely by:

• visiting TRG;
• scrolling;
• continuing to browse;
• creating an account;
• accepting Website Terms;
• making a Booking; or
• accepting the Privacy Policy.

***

46. COOKIE CONSENT AND CONTRACT ACCEPTANCE ARE DIFFERENT

Acceptance of:

• Website Terms;
• Customer Booking Terms;
• Provider Booking V2 Agreement;
• membership terms; or
• another contract

is not consent to optional cookies or tracking.

Cookie choices must remain appropriately separate.

***

47. COOKIE CONSENT AND MARKETING CONSENT ARE DIFFERENT

Accepting optional analytics or functionality technologies does not automatically subscribe a person to marketing.

Likewise, subscribing to marketing does not automatically authorise unrelated tracking technologies.

***

48. CONSENT REQUIREMENTS

Where consent is required, TRG must obtain consent that is:

• freely given;
• specific;
• informed;
• unambiguous; and
• demonstrated by a clear affirmative action.

Optional technologies must not be treated as accepted simply because the user ignores the banner.

***

49. NO PRE-TICKED OPTIONAL CHOICES

Optional consent choices should not be pre-selected in a way that purports to obtain consent through inactivity.

The user must make the required affirmative choice.

***

50. BEFORE CONSENT

Where a technology requires consent, it must not be activated before valid consent has been obtained.

This includes third-party scripts where loading the script itself causes the relevant storage or access.

***

51. REJECTING OPTIONAL TECHNOLOGIES

Users must be able to reject technologies requiring consent.

Rejecting optional technologies should not prevent access to ordinary functionality that does not depend on those technologies.

***

52. ACCEPT AND REJECT CHOICES

The consent interface should make meaningful choices available without manipulating users into accepting optional technologies.

Where Accept all is offered, users should also have an appropriately accessible way to reject optional technologies.

***

53. GRANULAR CHOICES

Where appropriate, users should be able to control different purposes separately.

Possible categories include:

• Essential;
• Preferences/Functionality;
• Analytics/Statistics; and
• Advertising/Targeting.

The exact categories displayed must correspond to the technologies actually used.

***

54. COOKIE SETTINGS

Users should be able to reopen Cookie Settings or an equivalent preference mechanism after their initial choice.

This allows applicable preferences to be reviewed or changed.

***

55. WITHDRAWING CONSENT

Where processing depends on cookie/device-access consent, users must be able to withdraw that consent.

Withdrawal should be as straightforward as giving consent.

Withdrawal does not make earlier lawful use unlawful.

***

56. OBJECTION TO EXEMPT STATISTICAL TECHNOLOGIES

Where TRG relies on the statutory statistical-purpose exception, users must be provided with a simple and free means of objecting as required by law.

This is distinct from consent.

***

57. OBJECTION TO APPEARANCE/FUNCTIONALITY TECHNOLOGIES

Where TRG relies on the applicable appearance/functionality exception, users must receive the required information and simple means of objecting.

***

58. EFFECT OF AN OBJECTION

Where a valid objection applies to a technology relying on one of these exceptions, TRG should stop the relevant storage/access for that user/device as required by law.

***

59. CONSENT AND PREFERENCE RECORDS

TRG may retain proportionate records demonstrating users' cookie choices.

These may include:

• preference selections;
• timestamp;
• policy/banner version;
• consent mechanism version;
• consent status;
• objection status; and
• a pseudonymous or technical identifier where appropriate.

Such records may themselves be necessary to remember and respect the user's privacy choice.

***

60. COOKIE-CONSENT TECHNOLOGY

A technology used solely to remember whether a user accepted, rejected or configured cookie choices may itself be necessary to honour that user's request and avoid repeatedly asking the same question.

Its duration should nevertheless be proportionate.

***

61. CHANGING OUR TECHNOLOGIES

TRG may:

• add technologies;
• remove technologies;
• change suppliers;
• change purposes;
• change durations; or
• change configurations.

Where a change affects consent or transparency requirements, TRG must update the relevant information and obtain fresh consent where legally required.

***

62. THIRD-PARTY CHANGES

Third-party services may change their own technologies.

TRG should periodically review relevant third-party integrations rather than assuming that an earlier cookie inventory remains accurate forever.

***

63. COOKIE INVENTORY

TRG maintains or should maintain a technical inventory recording, where applicable:

• technology/cookie name;
• provider;
• first or third party;
• purpose;
• category;
• duration;
• pages/features where used;
• whether consent is required;
• applicable exception;
• objection mechanism where required; and
• relevant third-party information.

***

64. DYNAMIC COOKIE NAMES

Some technologies use dynamically generated names.

Where appropriate, TRG may identify these using a naming pattern rather than attempting to publish every generated instance.

***

65. TECHNOLOGIES DEPENDENT ON USER ACTION

Some technologies arise only after a user:

• signs in;
• chooses a preference;
• opens a payment function;
• comments;
• uses a particular feature; or
• interacts with a third-party service.

They should not be described as operating on every visitor if they do not.

***

66. PLUGIN CAPABILITY DOES NOT EQUAL ACTIVE TRACKING

TRG uses WordPress software capable of supporting many integrations.

The fact that installed software contains code for a third-party service does not establish that TRG has enabled that service.

The published inventory should reflect actual deployment rather than every theoretical plugin capability.

***

67. BROWSER CONTROLS

Browsers generally allow users to:

• inspect cookies;
• delete cookies;
• block cookies;
• restrict third-party cookies; and
• clear site data.

Browser controls supplement TRG's own legally required controls.

They do not replace TRG's obligation to obtain consent where required.

***

68. CLEARING LOCAL STORAGE

Users may also be able to clear localStorage, sessionStorage and other site data through browser settings.

Doing so may remove saved preferences or require the user to sign in or configure features again.

***

69. BLOCKING ESSENTIAL TECHNOLOGIES

Blocking technologies necessary for requested functionality may prevent parts of TRG from working correctly.

For example, blocking authentication/session technologies may prevent a user from remaining signed in.

***

70. THIRD-PARTY PRIVACY INFORMATION

Where appropriate, TRG may provide links or references to relevant third-party privacy/cookie information through the live Cookie Settings interface or technology inventory.

A third party's policy does not replace TRG's own responsibility for technologies TRG chooses to deploy.

***

71. DATA PROTECTION

Where Storage and Access Technologies involve personal information, TRG must also comply with applicable data-protection law.

The legal basis for subsequent processing of personal information is a separate question from whether PECR requires consent to store or access information on the device.

***

72. OUR PRIVACY POLICY

Further information about:

• personal information;
• purposes;
• lawful bases;
• recipients;
• international transfers;
• retention;
• security; and
• individual rights

is contained in the TRG Privacy Policy.

***

73. CHILDREN

TRG account functionality is intended for people aged 18 or over.

TRG should take particular care before introducing tracking technologies likely to involve children's data.

***

74. SECURITY

Cookie and preference systems should be implemented securely.

TRG should not expose unnecessary personal information in cookie values or other client-side storage.

Sensitive information should not be placed in browser storage merely for convenience where a safer approach is reasonably available.

***

75. COOKIE VALUES

A cookie name may be public and visible through the browser.

This does not mean its value should contain unnecessary directly identifying or sensitive information.

***

76. ACCOUNT SECURITY

Authentication technologies should use appropriate security controls according to their purpose, including appropriate attributes and transport protections where applicable.

***

77. RETENTION AND DURATION

Technology duration should be proportionate to purpose.

TRG should periodically consider whether:

• session duration is sufficient;
• a persistent identifier is necessary;
• a shorter duration would achieve the same purpose; or
• the technology is still needed at all.

***

78. ADMINISTRATIVE TECHNOLOGIES

Some installed TRG software uses browser storage only within WordPress administrative interfaces.

These technologies may affect authorised TRG administrators rather than ordinary marketplace users.

They remain part of TRG's technical governance but need not be presented as ordinary visitor tracking where they are not encountered by ordinary visitors.

***

79. DEVELOPMENT AND TEST TECHNOLOGIES

Technologies used only in development, staging or diagnostic environments should not be represented as live production technologies unless they are actually deployed to users.

Production and test environments should be appropriately separated.

***

80. CACHE TECHNOLOGIES

Caching functionality can involve browser, server or intermediary caching.

Server-side caching alone is not necessarily a Storage and Access Technology on the user's device.

Where a caching system does use a browser cookie or other device storage, that component must be assessed according to its actual purpose.

***

81. SERVER-SIDE LOGGING

A server recording an incoming request, IP address, security event or Provider-profile view does not automatically mean a cookie has been stored.

Server-side processing is addressed primarily through the Privacy Policy.

If device information is also stored or accessed, this Policy additionally applies.

***

82. SOCIAL MEDIA

TRG may link to social-media pages.

A normal external link does not necessarily mean that TRG has embedded a social-media tracking technology.

If TRG later embeds tracking pixels, social plugins or advertising integrations, they must be assessed and controlled appropriately.

***

83. EMBEDDED CONTENT

Embedded third-party content may cause a third party to receive technical information or use device technologies.

Where such content requires consent, TRG should prevent it from loading before the required choice or use another compliant mechanism.

***

84. PAYMENT PAGES

Users should expect payment-related technologies when they actively enter a payment or checkout process.

This does not authorise unrelated advertising or tracking technologies.

***

85. PROVIDER DASHBOARDS

Technologies used in Provider dashboards may support:

• authentication;
• account preferences;
• membership;
• profile administration;
• Booking administration;
• analytics display; and
• security.

Each technology must be classified by purpose rather than treating the entire dashboard as automatically exempt.

***

86. CUSTOMER ACCOUNT AREAS

The same principle applies to Customer account functionality.

Authentication/security technologies may be necessary while unrelated analytics or advertising technologies require their own assessment.

***

87. NO SALE OF COOKIE CONSENT

TRG does not treat acceptance of optional tracking as payment for ordinary functionality unless a lawful and transparently designed arrangement expressly provides otherwise.

***

88. NO DARK PATTERNS

TRG should not design its cookie interface to:

• hide the reject option;
• make rejection materially more difficult than acceptance;
• use misleading button wording;
• repeatedly pressure users after refusal;
• or misrepresent optional technologies as mandatory.

***

89. RECONSENT

TRG may ask users to make a fresh choice where appropriate, including where:

• purposes materially change;
• new third parties are introduced;
• the previous consent is no longer sufficiently specific;
• applicable law requires it; or
• sufficient time has passed that renewed choice is appropriate.

***

90. PERIODIC AUDIT

TRG should periodically audit the live website using appropriate browser/developer tools and code review to identify:

• cookies;
• local storage;
• session storage;
• third-party requests;
• tags;
• pixels;
• embedded scripts; and
• other relevant technologies.

***

91. CODE AUDIT AND LIVE AUDIT

A source-code audit can establish that software is capable of using a technology.

It cannot always establish whether a feature is currently enabled, what configuration is active or whether a third-party service changes its behaviour at runtime.

For that reason, TRG should combine code review with live production testing.

***

92. CURRENT VERIFIED CODE FINDINGS

The technical review supporting this Policy identified, among other things:

• WordPress authentication/session functionality;
• UsersWP localStorage used for user-list display preferences;
• wpDiscuz sessionStorage capability for comment drafts;
• wpDiscuz comment/social-login cookie functionality where those features are enabled;
• Stripe.js integration through applicable GetPaid payment functionality;
• Wordfence security/login functionality; and
• administrative browser-storage functionality in WP Rocket.

The presence of functionality in code does not mean every listed conditional technology operates for every visitor.

***

93. TECHNOLOGIES NOT VERIFIED AS ACTIVE

TRG will not claim that optional integrations such as:

• reCAPTCHA;
• social-login tracking;
• advertising pixels;
• remarketing systems;
• behavioural advertising;
• Google Analytics;
• or another optional integration

are active merely because installed software contains support for them.

If activated, they must be added to the live inventory.

***

94. CURRENT ADVERTISING POSITION

Unless and until advertising/targeting technology is actually deployed, TRG should not populate the live cookie inventory with fictional advertising cookies.

If such technologies are introduced, the consent mechanism and this Policy must be updated before or at deployment as legally required.

***

95. LIVE COOKIE SETTINGS

TRG should provide an accessible Cookie Settings control where users can:

• review applicable categories;
• change consent choices;
• withdraw optional consent; and
• exercise applicable objections.

The control should remain reasonably accessible after the initial banner disappears.

***

96. RECOMMENDED TRG CONSENT INTERFACE

The TRG consent interface should distinguish at least:

Essential — always active where legally exempt

Technologies necessary for requested services and security.

Preferences / Functionality

Preference technologies, with consent or an applicable statutory exception/objection mechanism according to the particular technology.

Analytics / Statistics

Statistical technologies, with consent unless the applicable statistical exception is deliberately and correctly implemented.

Advertising / Targeting

Disabled until valid consent where such technologies are used.

***

97. INITIAL BANNER

A compliant implementation should give users clear information and meaningful controls before technologies requiring consent are activated.

The initial interface should provide straightforward routes to:

• Reject optional
• Accept all
• Manage choices

where those choices correspond to the technologies actually deployed.

***

98. CHANGES TO THIS POLICY

We may update this Policy to reflect:

• changes to TRG;
• new functionality;
• supplier changes;
• technology changes;
• regulatory guidance;
• or changes in law.

The current version should be made available through the website.

***

99. COMPLAINTS

Questions or concerns about TRG's use of cookies or other Storage and Access Technologies may be raised through TRG's current privacy/contact route.

Users also retain applicable rights to complain to the Information Commissioner's Office.

***

100. CONTACT

The Right Guy Ltd

3rd Floor

86–90 Paul Street

London

EC2A 4NE

United Kingdom

Company number: 16425623

VAT number: 495353361

ICO registration number: ZB924668

Current electronic privacy and support contact routes are published through The Right Guy website.

***

IMPORTANT COOKIE & STORAGE SUMMARY

The Right Guy's policy covers more than cookies. It also covers relevant browser storage, scripts, tags, pixels and similar device technologies.

Essential technologies may operate without consent only where the applicable legal exception genuinely applies.

A technology is not essential merely because a plugin wants to use it.

TRG's code currently confirms functionality including:

• WordPress authentication/session technology;
• UsersWP localStorage for directory display preferences;
• wpDiscuz sessionStorage for comment drafts where applicable;
• payment integration with Stripe;
• Wordfence security functionality; and
• some administrator-only storage.

Plugin support for a technology does not prove the technology is active.

TRG will therefore not invent cookie entries for optional integrations that have not been verified as deployed.

Qualifying statistical technologies may be capable of using the statutory statistical-purpose exception, but only where all legal requirements are satisfied and users have a simple means of objecting.

The same principle applies to qualifying appearance/functionality technologies.

Advertising, behavioural targeting and similar non-exempt tracking must not be activated before valid consent where consent is required.

Accepting TRG's Terms is not cookie consent.

Marketing consent is not cookie consent.

Continuing to browse is not treated as consent.

Users should be able to reject optional technologies, manage choices later and withdraw consent.

TRG should maintain and periodically re-audit its live technology inventory because plugins, configurations and third-party services can change. Thise are the first four i restored