Certificate and domain renewal obligation register
Problem
Certificates and domain names for club sites, ticketing portals and fan apps get bought by whichever team stood up the service, often years apart and through different suppliers. The renewal date sits in the engineer's calendar, or in an email nobody reads until it fires, or nowhere: the person who registered the domain left eighteen months ago and the registrar login lives in a shared note nobody has opened since. IT rarely holds a single list of what is registered, who owns it and when it lapses. When a certificate expires, visitors hit a browser warning instead of the ticketing page, usually on a matchday, and IT finds out from a support ticket or a message in the team chat rather than its own monitoring.
Product idea
A register listing every TLS certificate and every domain name in use across the estate, its expiry date, which certificate authority or registrar issued it, and a named owner. The register escalates automatically as an expiry date approaches, first to the owner and then upward if nothing changes, so a lapse is flagged to a person rather than left to a calendar reminder that may or may not fire. Marking an item renewed requires uploading evidence, a confirmation email or invoice, so the register also becomes the record an auditor can be shown. It does not hold registrar credentials and does not renew anything itself: it tracks and escalates, and the actual renewal still happens wherever it always has.
Who it is for
Head of IT and information security officers who need an audit-ready record, and the service desk lead who takes the call when a certificate lapses mid-shift.
Possible first version
A CSV import of existing certificates and domains with expiry date, issuer and owner, a dashboard sorted by how soon each item lapses, and email escalation to the owner as the date nears. Marking an item renewed requires an uploaded confirmation file, building the audit trail from day one. Out of scope for version one: no automatic scanning or discovery of certificates across the network, no integration with domain registrars or certificate authorities, and no auto-renewal. Everything is entered and updated by hand.
- Build classification
- Workflow application
- Rough effort
- 4-6 week first release
- Roles involved
- Head of IT, Information security officer, Service desk lead
- Relevant to
- Professional club, League office, Federation / governing body, Venue & stadium operator
- Systems in play
- Spreadsheets, Service desk and ticketing tools, Document management and intranets
- Product framing
- Manage compliance
Questions we get asked
What do we need to give this to get started?
A list of what already exists: every TLS certificate and domain name you can find, who bought it, and when it is due. Most organisations do not have that list to hand, and building it is usually the first real value the project delivers, before the register even starts escalating anything. Version one takes that list as a manual import rather than scanning the network for you, so the quality of what goes in on day one determines what the register can protect from day one.
Does this replace how we buy and renew certificates?
No. Renewal still goes through whichever certificate authority or domain registrar you already use, and this tool holds no registrar credentials and cannot renew anything on your behalf. What it changes is visibility: instead of one person's calendar knowing a certificate is due, the register knows, and it tells a named owner before the date passes rather than after a visitor sees a browser warning.
We already track this in a spreadsheet tab. What does this add?
A spreadsheet works exactly as well as the person who maintains it. It stops working the day that person changes role, goes on leave, or simply stops opening the tab. The register makes ownership explicit for every entry and escalates on its own rather than depending on someone remembering to check a tab. If your spreadsheet is actively checked every week by a named person, you may not need this yet.
Who has to keep this up to date once it exists?
Whoever provisions a new certificate or registers a new domain has to log it at creation, which is the point most registers currently fail on: nothing enforces that step today. Head of IT or the information security officer would own periodic review of the whole list. If nobody adds new entries as services are stood up, the register decays in exactly the way the current spreadsheet or calendar reminder already does.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in IT, data, compliance & knowledge
- Data retention and deletion obligation registerA register that tracks retention deadlines for datasets holding personal data across the technology estate and escalates to a named owner before deletion or review falls overdue.
- Integration heartbeat monitor and owner escalation boardA live board of every integration's last successful run that escalates to a named owner before a missed sync turns into a bad report or an angry ticket.
- Internal policy and IT process chat assistantA chat assistant that answers routine IT and policy questions from existing documents and routes what it cannot answer to the service desk, instead of staff guessing or re-asking.