Security

Signing in

• Passwords are at least 10 characters, checked against known breached passwords, and stored only as a scrypt hash.
• Email addresses are confirmed before the first sign-in.
• Two-factor sign-in with an authenticator app, plus one-time backup codes. Owners can require it for everyone who signs in with a password, and it’s on by default for new workspaces. It’s enforced by the server on every request, so it can’t be skipped.
• Microsoft 365 sign-in, where your organisation’s own multi-factor authentication and conditional access apply. Microsoft accounts are only linked to existing accounts in ways that can’t be used to take one over.
• Repeated attempts are rate-limited and checked for bots. Changing a password signs out every other session, and you can sign out other devices yourself.
• Sensitive changes, such as security settings, owners’ roles or deleting a workspace, ask you to confirm it’s you if you haven’t signed in recently.
• You’re emailed when your password or two-factor settings change, and owners are emailed when someone becomes an owner or admin.

Who can see what

• Workspaces are invite-only. Owners choose who joins and give each person a role: Owner, Admin, Member or Viewer.
• Only owners can appoint or remove owners, and a workspace always keeps at least one.
• Invitation links can only be seen by the people allowed to send invitations.
• Every request is checked against the signed-in person’s membership, and every database query is limited to that workspace. Automated tests try to reach one workspace’s data from another, for every role, on every change.
• Changes to clients, returns, tickets, the team and settings are recorded in an activity history the practice can see.

Protecting every request

• HTTPS only, with TLS 1.2 or later and HTTP Strict Transport Security.
• A Content Security Policy that only loads scripts, styles and connections from Yeardesk itself, and pages that can’t be framed by other sites.
• Changes have to come from Yeardesk itself, which blocks cross-site request forgery.
• Every input is validated on the server.
• Cloudflare’s web application firewall and DDoS protection sit in front of the app.

Where the data lives

• The database is in London, encrypted at rest, and reached only through Cloudflare with an account that has just the permissions the app needs.
• Backups: 7 days of point-in-time restore, plus nightly backups that are encrypted before they leave the database and kept for 30 days. Restoring them is tested every month.
• Emails about signing in contain links that work like passwords, so we keep only a record that each email was sent, never its contents.
• The full list of services that process data for us is on the sub-processors page.

Running it

• Errors are reported to us without names, email addresses, client data or request contents.
• We’re alerted if Yeardesk or its database stops responding.
• Every code change is reviewed and tested automatically before release, dependencies are kept up to date, and secrets are kept out of the code.
• Development tools and demo data are switched off in production, and the app won’t start with weak or missing secrets.

If something goes wrong

We have a written plan for security incidents. If a breach affects a practice’s data, we’ll tell its owners without undue delay, and within 48 hours, so they can meet their own duties. Where the law requires it, we report breaches to the Information Commissioner’s Office within 72 hours. The data processing addendum sets out what we’ll tell you.

Reporting a vulnerability

If you think you’ve found a security problem in Yeardesk, please email security@yeardesk.com with enough detail for us to reproduce it. We’ll reply within a few working days and keep you updated while we fix it. Our contact details are also in security.txt.

Please don’t access or change other people’s data, disrupt the service, or share the problem publicly before it’s fixed. We won’t take action against research done in good faith within these limits.