A short policy,
because we set very little.

A cookie is a small file a site asks your browser to store and send back on later requests. It is the ordinary way a web application remembers that the person making this request is the same person who signed in a minute ago, because HTTP itself remembers nothing between requests.

The word is also used loosely for related browser storage such as local storage and session storage. Where we use those, we treat them under this policy too, because from your point of view the question is the same: what is being kept on your device, and why.

This policy covers both the public marketing website you are reading now and the DenwaysHR application your employer signs into. They behave differently and it is worth keeping them apart.

This marketing site is close to static. It has no login, no basket and no personalised content, so there is very little for a cookie to remember. We would rather say that plainly than pad this page out.

Without asking, the site stores two things, both in your browser's local storage and neither sent to us: your light or dark theme choice, so the page does not flash the wrong colour scheme on your next visit, and your answer to the cookie prompt, so you are not asked again on every page.

The one optional thing is Google Analytics, which we use to see which pages get read. It sets cookies whose names start with _ga, so it stays off until you accept it in the prompt shown on your first visit. If you decline, or leave the prompt unanswered, it is never loaded.

You can change your answer at any time with Cookie settings in the footer of any page. Taking back a yes switches Google Analytics off and removes its cookies. Your answer is kept for twelve months and then asked for again.

The application is where cookies do real work. Signing in creates a session, and the session has to travel with every request you make so the server knows which user and which organization it is answering.

Those cookies are set as HTTP-only, which means page scripts cannot read them, and as secure, which means they are only ever sent over an encrypted connection. That combination is what stops a script injected into a page from lifting your session and using it elsewhere.

They are scoped to the application host, not to this marketing site, so browsing these pages does not send them anywhere.

A small set of cookies is strictly necessary. Blocking them does not degrade the experience, it breaks sign-in outright, and no consent banner can honestly offer them as optional.

We do not currently run third-party advertising or cross-site tracking cookies on this website, and we do not build advertising profiles from anything you do here.

Where product analytics is used inside the application, it is scoped to helping the operator understand which features are used and where users get stuck, and it is not used to profile individual employees for their employer.

Our consent position is straightforward. Strictly necessary cookies are set because the service cannot run without them. Anything beyond that category is opt-in, asked for before it is set, and withdrawable afterwards. On this website that category holds one thing today, Google Analytics, and when we load it we tell it not to use what it collects for advertising.

A third-party cookie is one set by a domain other than the one you are visiting. They usually arrive with embedded content such as a video player, a chat widget, a font service or a tag manager.

We keep embedded third-party content on this site to a minimum precisely because each embed is an opportunity for someone else to set a cookie in our name. Where an embed is unavoidable, we prefer providers that offer a cookie-free or privacy-preserving mode.

The infrastructure in front of the application, which provides firewall rules, denial-of-service protection and bot mitigation, may set a technical cookie to distinguish a legitimate browser from an automated one. That is a security function, not an advertising one.

Every mainstream browser lets you see what has been stored, delete it, and block categories of cookie in advance. The controls sit under settings, usually labelled privacy, security or site data.

Blocking cookies on this marketing site costs you almost nothing. At worst a theme preference is forgotten between visits.

Blocking cookies on the application is a different matter. Without the session cookie you cannot stay signed in, and without the request forgery token your submissions will be rejected as unsafe. If sign-in loops back to the login screen, an over-broad cookie block is the first thing to check.

If your organization runs a managed browser policy that blocks cookies by default, the application host needs to be allowed for the product to work at all.

This page is updated whenever what we set changes, and the date at the top always reflects the current version. We would rather revise it before a change ships than describe it afterwards.

If we introduce a category of cookie that requires consent, you will see a prompt on your next visit rather than a silently updated policy. Material changes affecting the application are also sent to account administrators.

Privacy questions, including anything about what is stored on your device, can be sent to info@denways.com. Security concerns go to info@denways.com.

If you are an employee of a company that uses DenwaysHR and you have a question about data held in your own record rather than about cookies, your employer is the right first point of contact.