Security at Tagnator

Last updated 11 November 2026. Applies to every Tagnator product and to this website.

Tagnator is Nathan Jones, trading as Tagnator, a sole trader in the United Kingdom. Nathan runs the business. The software is built by Claude, an AI model made by Anthropic, working under Nathan's direction. This page explains how to report a security problem, how quickly we fix one, how we tell customers and Atlassian, what we do and do not do, and what we do if something goes wrong.

1. Report a vulnerability

Email support@tagnator.com with "Security" at the start of the subject. Please include:

• the product and, if it shows one, its version;
• what the problem is and what an attacker could do with it;
• the steps to reproduce it, or a short proof of concept;
• where you tested it: your Jira or Confluence site address, your WordPress and PHP versions, or your Android version;
• whether you have seen it used against anyone;
• whether, and how, you would like to be credited.

Please do not send passwords, API keys or other people's data. Test only against your own Atlassian site, your own WordPress site or your own device. Do not access, change or delete data that is not yours; if you come across some, stop and tell us what you saw rather than keeping a copy. Do not run denial-of-service tests, and do not target our customers, Atlassian or us with phishing or social engineering.

We do not offer encrypted email. If your report is sensitive, send a short first message without the exploit details and we will agree how to receive the rest.

Problems in Atlassian's own products (Jira, Confluence or the Forge platform) go to Atlassian: report a vulnerability to Atlassian. Reports about our apps that reach us through Atlassian's Marketplace Security (AMS) project follow the same process as email reports.

2. After you report

• Acknowledgement: within one working day (Monday to Friday, 09:00 to 17:30 UK time, as in our service level agreement).
• First assessment: within two working days of your report. We tell you whether we can reproduce the problem and the severity we give it, scored with CVSS version 3.1.
• Updates: whenever the status changes, and when the fix is released.
• Credit: in the release notes, if you want it.
• No bug bounty: we do not pay rewards for reports.
• Disclosure: please keep the details private until we have released a fix, or until the fix timeline for its severity (below) has passed. We will agree a publication date with you.

3. Products and supported versions

We fix security problems in the current version of each product only. A fix is always released as a new version; we do not patch older versions.

Product and where it runs	Supported version	How a fix reaches you
Markdown Writer for Jira, Sprint Scope Search for Jira and Restriction Guard for Confluence: Atlassian Forge apps for Jira Cloud and Confluence Cloud	Current version	Atlassian applies new versions to every site automatically. If a fix needed new permissions, a site admin would be asked to approve it, so we write security fixes that do not need new permissions wherever we can.
EAA Ready: a WordPress plugin on your own site	Latest release	Update from the WordPress dashboard, or automatically if you have turned on automatic updates.
Tagnator PDF: an Android app that works offline on your phone	Latest version	Google Play updates.
NIS2 and Cyber Essentials kits: documents and spreadsheets sold through Polar	Latest files	We replace the files in Polar and email buyers.
Esc Tools (esctool.com) and tagnator.com: websites on Cloudflare Workers	The live site	We deploy the fix; there is nothing for you to do.

Our Forge apps run entirely on Atlassian's infrastructure. We run no servers for them and they make no calls outside Atlassian. Sprint Scope Search and Restriction Guard keep records in your site's Forge storage, which we cannot read; Restriction Guard's records include Atlassian account ids. Our privacy policy sets out what each product stores. We have no Data Center or Server apps.

4. Fix timelines

Each confirmed vulnerability gets a CVSS 3.1 base score, and the score sets how quickly the fix must be released.

Severity	CVSS score	Fixed within
Critical	9.0 or higher	10 days
High	7.0 to 8.9	4 weeks
Medium	4.0 to 6.9	12 weeks
Low	below 4.0	25 weeks

The time runs from the report or, if the report needed checking first, from when we confirmed it. These are the maximums in Atlassian's security bug fix policy for cloud apps. We apply them to every product, not just the Atlassian apps, and aim to release critical and high fixes sooner. "Fixed" means a corrected version is released: for a Forge app, deployed to production.

If a fix depends on Atlassian, Google or another supplier, we put a mitigation in place where one exists, tell the reporter, and for a Marketplace app ask Atlassian for an extension on the AMS ticket, as the policy allows.

5. How we tell customers and Atlassian

Customers

When a vulnerability of high or critical severity affected a released version, or customer data may have been exposed, we tell the customers affected. We follow Atlassian's app vulnerability notification template for every product. Each notice says:

• the product, the version where the problem was found, and every version it affected;
• what the vulnerability is, what an attacker could do with it, and whether any customer data may have been exposed;
• the period during which it was present;
• its severity on the CVSS scale;
• how and when it was found, and by whom;
• what we did to investigate it and what we changed to fix it;
• whether there is any sign it was used, and the effect on customers;
• what you need to do: nothing for the Forge apps and websites, or how to update for the WordPress plugin and the Android app;
• who to contact with questions, and the name of the person sending it.

We write honestly and completely, and we do not play down what happened. Notices go out by email where we have a customer contact: through Polar for the kits, and through the shop that sold the licence for EAA Ready Pro. For the Forge apps we work through Atlassian, which can reach every site with the app installed, and we post a notice on the Marketplace listing. For the free WordPress plugin, the Android app and Esc Tools we publish the notice in the release notes and on the product's page.

Atlassian

For a vulnerability in one of our Marketplace apps, we report and update on the app's ticket in Atlassian's Marketplace Security (AMS) project, raising one ourselves when we found the problem (Atlassian's instructions). For a security incident, we raise a P1 ticket through Atlassian's ecosystem service desk within 24 hours: see the incident response plan below.

6. How we build and run our products

• Source code is kept in a private GitHub repository, and the accounts that can reach it use two-factor authentication. Every change is recorded with its date, so any release can be traced and rolled back.
• Access to the source code and to the accounts we publish through (Atlassian, WordPress.org, Google Play, Polar, Cloudflare, GitHub) is limited to Nathan, and to Claude working on his development machine.
• Automated tests run before every release: unit tests and Atlassian's forge lint for the Forge apps, unit and in-WordPress tests on several PHP versions plus WordPress's Plugin Check for the plugin, on-screen tests on an Android emulator for the Android app, and page checks for the websites.
• Dependency checks: we run npm audit on the Forge apps before each release, and treat each finding that affects our code under the fix timelines above.
• No customer data on our own systems. The Forge apps run inside Atlassian, the WordPress plugin stores its data in your WordPress database, and the Android app keeps your documents on your phone. We run no servers that hold customer content. The only customer details we keep are support emails and sales records, described in our privacy policy.
• Secrets (API tokens, signing keys, passwords) are kept outside the source repository, in files only the owner's account on the development machine can read. The repository's ignore list keeps secret files out of it.
• Development workstation: a Mac with full-disk encryption (FileVault) and automatic macOS security updates.
• Websites are static pages served with a content security policy, and they refuse to be framed by other sites.

7. What we do not do

• We hold no security certifications: no ISO 27001, SOC 2 or Cyber Essentials.
• We have had no external security audit or penetration test yet.
• We run no bug bounty and pay no rewards.
• We have no out-of-hours rota. The support mailbox is read on working days, and the timelines in our incident plan run from when we become aware of an incident.
• We have no incident response firm or legal adviser on retainer. If an incident needs one, Nathan will engage one.
• We keep no request logs for our websites, by choice, for privacy. The Forge apps' logs are kept by Atlassian in its developer console.
• We do not publish a PGP key.

8. Incident response plan

This plan follows Atlassian's app security incident management guidelines and preparing for a security incident. We use it for every product.

What counts as an incident

• Actual or suspected unauthorised access to, or use, disclosure, change or destruction of, customer data held by us or by a supplier on our behalf.
• A compromise of one of our products, or of an account or key used to build or publish them.
• For the Forge apps, anything our app does that materially degrades Atlassian's systems.

A vulnerability with no sign of use follows the vulnerability process above. Once there is a sign it has been used, it is an incident.

Roles

Who	Role	Does
Nathan Jones	Owner and incident lead	Decides the severity and every action. Approves and publishes releases. Contacts Atlassian, customers, our suppliers and the Information Commissioner's Office (ICO). Signs customer notices. Holds the accounts.
Claude	Builder	Investigates the code and logs, prepares and tests the fix, and drafts the Atlassian ticket, customer notice and incident record. Releases, deploys and sends nothing without Nathan's approval.

Other contacts: Atlassian's ecosystem service desk, and the support teams of Polar, Freemius, Google Play, WordPress.org, Cloudflare and GitHub.

Severity levels

Level	Meaning	Response
1. Critical	Customer data exposed or very likely exposed; a product, publishing account or signing key compromised; or a vulnerability being used against customers.	The full plan, starting at once. Atlassian is told if a Marketplace app is involved.
2. Serious	Any of the above suspected but not confirmed; or a secret exposed with no sign it was used.	The full plan. Atlassian is told if a Marketplace app may be involved.
3. Minor	A security event with no customer data or product at risk, such as a failed attack, a phishing attempt on our accounts, or a supplier's incident that does not touch our products.	Contain, record and review.

Within 24 hours of becoming aware

1. Record: open an incident record with the time we became aware and what we know.
2. Assess: set the severity level.
3. Contain: revoke and replace exposed tokens and keys; roll back, fix or switch off the affected version or site; and where needed, ask Atlassian, WordPress.org, Google Play or Polar to suspend the product, including delisting a Marketplace app.
4. Notify Atlassian (level 1 or 2 with a Marketplace app involved): raise a P1 ticket through Atlassian's ecosystem service desk promptly, and no later than 24 hours. It covers what we know so far: the type and scope of the incident, how long it lasted, whether customer data was affected, the likely number of customers, the types of data, the expected time to resolve, containment taken and planned, our plan for telling customers, the root cause if known, the actions to stop it happening again, and a contact name, email and phone number.
5. Update Atlassian at least every 6 hours while containment is in progress.
6. Keep evidence: keep the Forge app logs, deployment history and account audit logs; delete nothing.

Within 72 hours

7. Investigate: find the root cause, how long the problem existed, and which customers and data were affected.
8. Tell customers who were affected, where possible within 72 hours of identifying the incident, using the notice described above.
9. Tell the ICO within 72 hours if personal data we control was breached and the breach is likely to put people at risk, as UK GDPR requires (ICO breach reporting).
10. Fix: release the fix within the timelines above, sooner where we can.

Until it is resolved

We keep Atlassian and affected customers updated and answer Atlassian's requests for information. If Atlassian asks, we confirm in writing that the incident is resolved and that we have met our legal duties to tell people.

Post-incident review

Within two weeks of resolving an incident we write a review: what happened and when, the root cause, what worked and what did not, whether any sign of compromise remains, whether our logging needs to improve, and what we are changing so it does not happen again. For a Marketplace app we send the findings on the original Atlassian ticket. Affected customers receive a summary. We review this plan after every incident and at least once a year.

Atlassian's timelines

When	What
Within 24 hours	Notify Atlassian of a security incident with a P1 ticket through the ecosystem service desk.
Every 6 hours	Update Atlassian while containment is in progress.
Within 72 hours	Notify affected customers, where possible.
After the review	Send the post-incident findings on the original ticket.
10 days to 25 weeks	Fix vulnerabilities by severity, as in fix timelines.

9. Contact

Security reports and questions: support@tagnator.com. The same details are in machine-readable form at /.well-known/security.txt. Postal address: Nathan Jones, trading as Tagnator, The Crosse House, Balls Farm Road, Exeter, EX2 9HZ, United Kingdom.