Privacy Policy

Sentinel Command is a media accreditation platform. Event organizers use it to run accreditation for their events; media outlets use it to apply on behalf of their journalists.

This policy is issued by Sports Solutions Consulting, LLC. Questions about it go to Privacy@MediaCredentialing.com.

The system holds data about three groups, and it matters which one you are, because your data reaches us by different routes and we answer for it differently.

Clients are the organizations putting an event on, and the named people at them who sign in.

Media contacts are the people at a media outlet who file applications.

Attendees are the journalists, photographers, TV, radio and online broadcasters, and support staff who applied themselves or who have been applied for by others at their employer for event media accreditation.

From clients and media contacts, who give it to us directly: name, professional title, email address, phone number, and the organization they act for. For clients we also store a password, hashed. Media contacts have no password — they sign in with a code emailed to them that is unique for each session with the service.

From media contacts, their outlet’s answer to whether events may send its people text messages, kept together with the evidence of that answer. Section 13 describes it.

About attendees, given to us by their media outlet and not usually by them: name as it appears on their identity document, the type, number, issuing authority and expiry date of that document, email address, phone number, their role and job title, and a photograph. This is the sensitive material in the system, and the outlet supplying it is responsible for having the authority to do so.

Automatically, as a consequence of running the service: sign-in attempts, with the time, the identity tried, whether it succeeded, and the IP address it came from. Every change to an application's status, with who made it and when. Anything written in the feedback box in the help dialog, with the page it was written from and the signed-in identity, if any.

About people a client shares a report with, who are not users of this system and may never have heard of it: the name and email address the client gave when creating the link, and a record of every time that link was opened — the date and time, the IP address it came from, and the browser it announced itself as. Section 8 explains why. This is the only personal data we hold about somebody who has no account or active role with this service.

From clients who reach the paid service, a billing record: which calendar month was billed, how many applications it covered, the price each, the total, whether the charge succeeded, and Stripe’s reference for the invoice. Alongside it, enough about the card to recognize it — the brand, the last four digits and the expiry month and year — and nothing more. Section 7 says what happens to the card number itself.

This one deserves its own paragraph, because it is the least obvious thing the system does.

To help an organizer check that an applicant is a working member of the media, the system can search public sources for that person and produce a short summary of what it found, together with links to the sources it read. To do this it sends the applicant's name, email address, job title, role, the issuing authority of their identity document and their outlet's details to Anthropic's Claude API, which performs the search.

It searches only for evidence that the person is a working journalist employed by or regularly publishing for the outlet they name. It is not a background check, a criminal-records search or an adverse-media screen, and it cannot be used as one.

The result is an aid to a human decision and never the decision itself. It can and does surface a different person with the same name, which is why the sources are always shown alongside it and why the summary must be checked before it is relied on.

To run accreditation: letting outlets apply, letting organizers decide, and recording what was decided. To let people sign in and to keep other people out, which is what the sign-in records and rate limits exist for. To send the transactional emails the service depends on — sign-in codes, welcome messages, password resets, and the billing messages described in section 7.

To let a client show a report to somebody else inside or potentially outside their organization, and to tell that client where the link has been opened from. The access record exists so a client can see a link being used by more people than they gave it to, and turn it off — see section 8.

To bill for the service. Once a client passes the free allowance we count the applications their events received in a calendar month and charge for them. Nothing about an attendee reaches our payment provider: what is billed is a NUMBER of applications, not who they were for.

We do not sell personal data, we do not use it to train any model, and we do not send marketing email off the back of it.

The event organizer the media outlet applied to. An application exists to be read by them; that is the point of filing it.

Railway, which hosts the application and its database. Resend, which delivers our email. Twilio, which delivers text messages and receives only the mobile number and the message — see section 13. Anthropic, for the open-source verification described in section 4, and only for the applicants it is run on. Stripe, which takes the payments described in section 7, and only for clients who reach the paid service.

Anybody a client gives a report link to. That is the client’s decision rather than ours, and section 8 sets out what we do and do not do about it.

Nobody else. There are no advertising networks, no analytics trackers and no data brokers in this system.

Card payments are taken through Stripe. This section is longer than the others because credit card data security is very important.

We never see your card number. When you add a card you are sent to a page Stripe hosts, on Stripe’s own domain, and the number, expiry and security code are typed there. They are never sent to our servers, never pass through our code, and are never written to our database — there is no column for a card number, and the value is never seen by our service.

What comes back to us is a reference and a description: Stripe’s identifier for you as a customer, its identifier for the saved card, and enough to tell one card from another — the brand, the last four digits, and the expiry month and year. The security code is never stored, by us or by anybody, once the card is set up. When we show you “Visa ending 4242”, those four digits are the whole of what we hold.

What we send to Stripe is your company name, the email address on the account, and the amount to charge. No attendee data, no application, no identity document and no photograph is ever sent to Stripe.

How the charge is worked out: the first 50 attendee applications on an account are free, once, for the lifetime of the account rather than monthly. After that, applications are counted per calendar month and billed at 99 cents each. The charge is made in arrears, on the 1st of each month for the calendar month just ended — never in advance — and we email a receipt after each successful charge showing the card that was used and the arithmetic behind the amount.

If a charge is declined, Stripe tells us, we email you saying so and what the issuer gave as the reason, and the account is suspended until a payment succeeds. Suspension means you can sign in and reach the billing page and nothing else; applications keep arriving and nothing is deleted.

You can replace or remove the card from the billing page at any time, which sends you back to Stripe’s hosted page to do it.

Stripe is its own data controller for the payment it processes, under its own privacy policy, and holds the card data we do not. (Stripe’s Privacy Policy: https://stripe.com/privacy)

A client can create a link that lets one named person read one of their reports without having an account here. It is meant for somebody like a communications director who needs to see numbers as they stand rather than a spreadsheet emailed last week.

What that person sees is the report, live. Depending on what the client put in it, that can include the names of individual journalists, the outlets they work for, their job titles, and the status of their applications.

The client decides who gets a link, and the client is responsible for that decision. We do not choose the recipients, we do not check whether somebody is entitled to see the people named in a report, and we warn the client of exactly this on the screen where the link is created.

What the link does to limit the risk: it is issued to one named person and one address, not to a group; the first time it is opened it asks for that address and emails a six-digit code to it, so it cannot be used by somebody it was passed on to without their help; it expires on a date the client sets; the client can revoke it at any moment; and every attempt to open it is recorded and shown to the client, including the IP address.

What it cannot do, stated plainly because it matters: it cannot stop the recipient forwarding the link, describing what they saw, or photographing the screen. No link can, here or anywhere. What the measures above buy is that a leak is visible to the client, awkward for whoever it reached, and can be cut off.

The page itself names the person it was shared with, so a copy of it carries its own source.

If you are an attendee and your details may have reached somebody this way, the organization that filed your application and the event organizer who holds the report are the two parties who decided that. Section 12 says where to ask.

Only the cookies that keep you signed in, one per portal. They carry a random token and nothing about you, and what is stored at our end is a hash of that token rather than the token itself, so a copy of our database does not hand somebody a working session.

One more, for somebody opening a shared report: once they have answered the emailed code, a cookie records that this browser has done so, for that one link, for twelve hours. It is why they are not asked for a code on every page. It carries no address and no name, and a cookie for one link does not open another.

There are no advertising or analytics cookies, which is why this site does not ask you to accept any.

Passwords are hashed with scrypt and a per-record salt, so they cannot be read back — not by us either. Session and password-reset tokens are stored as hashes. Repeated failed sign-ins block both the connection and the identity for a period. A request for something you are not entitled to is answered as though it does not exist, so nothing can be probed for.

No system is perfectly secure, and this one is young, so any incident will be documented and retained for mitigation, repeat elimination and archival purposes. All legal obligations to notify impacted companies and individuals will be fully complied with.

Accreditation records, and the audit trail of decisions made about them, are kept as a permanent record of who was credentialed for what — an audit trail that can be edited or erased is not an audit trail.

A shared report’s access record is kept for as long as the link exists and is removed with the report it belongs to. Revoking a link does not erase its history: a client asking “where had this been opened before we cut it off” is exactly the question the record exists to answer.

Billing records — which month was billed, for how many applications, at what price, and whether it was paid — are kept for as long as tax and accounting rules require them, which is the ordinary reason anybody keeps an invoice. The card description beside them is replaced whenever the card is, and goes with the account.

Retention periods for roster entries with identity document details, and personal information about media outlet employees, are under the control of the media outlet, which can delete any roster files at any time. The retention period for sign-in history and feedback is one year.

Depending on where you live you may have the right to see the personal data held about you, to have it corrected, to have it deleted, and to object to how it is used.

Where to ask depends on who you are. If you sign in — as a client or a media contact — write to us at Privacy@MediaCredentialing.com. If you are an attendee somebody applied for, the outlet that filed the application holds and controls your record; ask them first, and email us if that gets you nowhere.

Event organizers who use the service can send text messages to the mobile numbers on the applications for their event. They are meant for urgent, time-sensitive notices about that event, and for nothing else: no marketing and no promotions are sent by text. The organizer writes the message and decides when it goes; the service is what it is sent through.

Whether an outlet’s people may be sent these messages is asked on the media contact form, where the outlet registers and where its details can be changed. We keep the answer together with its evidence: the exact wording of the question and of the answer as they were shown, which account gave it, when, and the IP address and browser it was given from. A changed answer is added to that record rather than written over it, so the history of who agreed to what, and when, is kept.

Message frequency varies with the events you are credentialed for. Message and data rates may apply. Reply STOP to any message to stop receiving them, or HELP for help. You can also write to Support@MediaCredentialing.com.

To deliver a message we send the mobile number and the text of the message to Twilio, which passes it to the mobile carrier. Nothing else about the person receiving it is sent.

Mobile numbers are not shared with, or sold to, any third party or affiliate for marketing or promotional purposes. Text-message opt-in data and consent are not shared with any third party.

The consent record is kept for as long as the outlet’s account exists, because it is the proof that the messages sent to its people were permitted.

This page is where changes appear, and the date under the heading is when it last changed. Any subsequent changes will be posted here, with no automatic notification to any system user.