Personal data

This is an information translation. The binding text is the Russian one at pominutam.ru/privacy; where the two differ, the Russian text prevails.

Who runs the service, and what this text is

“Po minutam” is run by the author of the service, who also answers the support mail. Below is what the service actually keeps in its database and files, what for, for how long, and who it is passed to. The text describes the behaviour of the running code, not intentions.

The operator of the personal data is Mikhail Andreevich Nikishin, an individual entrepreneur, INN 420538869458, OGRNIP 324420500016611; the full details are in section 15 of the offer. The operator is listed in the Register of operators processing personal data kept by the Federal Service for Supervision of Communications, Information Technology and Mass Media (Roskomnadzor), registration number 78-25-169791. The processing described on this page is covered by that notification: no separate notification was filed for “Po minutam”.

Revision of this text: 2026-10-08. That date is the “consent version”: it is written into the account at sign-up or on the consent screen at the first sign-in, so it is always clear which revision of this page and of the offer the person accepted. Change the text, change the date.

There are two kinds of people here, with very different amounts of data. An organiser creates an account in one of three ways: with an e-mail and a password, with a link sent to their e-mail, or with Yandex ID. A participant of an event (speaker, host, viewer) creates no account: they enter by link, and everything the service knows about them was typed in by the organiser — or by themselves, by pressing “that’s me”.

What is collected about an organiser

E-mail, name, short name, the default role caption, interface language, photo. All of it is entered by the organiser in the profile; with Yandex ID sign-in the name, the e-mail and the photo come from Yandex (see the next item).
When signing in with Yandex ID, the Service receives data from Yandex LLC with the user's consent given in the Yandex ID interface and saves only the name, the e-mail address, the Yandex account identifier and — only if the profile in the Service has no photo of its own — a copy of the Yandex profile photo. The copy is kept in the Service's own storage; the address of the photo at Yandex is not saved, and a Yandex sign-in never replaces a photo the profile already has. The person can replace or remove it in the profile; once removed, the photo is not taken from Yandex again until the person uploads a new one themselves. It is also deleted together with the account. The rest of the Yandex profile is not saved.
The password, if the organiser signs in with one — only as an irreversible hash; the original is not in the database.
The consent mark: the revision date of this text at the moment of sign-up or of consent on the first sign-in screen.
Sign-in sessions: a technical token, its expiry, the IP address and the browser string (User-Agent) of the device that signed in.
The account plan and the paid-access date.

What is collected about an event and its participants

The event: title, date, start time, time zone, board language, declared duration, the participant and host PINs, the link addresses — including the hall-screen key that opens the board without a PIN.
The programme: stages, planned minutes, the host of a stage, the stage script written by the organiser, the actual start and finish marks, stage comments.
The organiser’s people directory: name, short name, role caption, photo, note.
Event participants: name, short name, role caption, kind of participation, photo, the personal invite token, and a link to an account if the participant pressed “that’s me”.
Preparation checklists — items built from the programme, items added by hand, and the ticks on them.
The mark of the first opening of the event: the date and time the organiser moved the event into the “open” state and the board links started working. It is set once and never removed, even if the event is moved back to a draft: clauses 6.4 and 7.7 of the offer rest on that fact — it shows whether the Meeting Right was used and whether it can still be bought back.
The action log: who opened the event, moved it back to a draft or finished it, who started or finished a stage and when, who adjusted the plan, left a comment, reset the progress, edited the programme or the people. The actor’s caption is stored as text, and an edit also stores “before” and “after” snapshots of the value — that is, the previous text of the field too.
Presence on the board: for each participant, the time of the last signal from their page; for the event, the peak number of boards open at once.
AI assistance action accounting: for every call to the model — the account, the event, the time, whether it succeeded and how many model tokens it spent. Neither the text of the request nor the model's answer is kept in that record: it exists to count the plan quota and the owner's spending.

Participants' data: who answers for it

Names, short names, role captions and photos of participants are entered into an event by the organiser — that is, third-party personal data reaches the service. Under the personal data law the roles here differ, and they must not be confused.

The organiser is the data controller. They decide whom to add to an event, what to record, and whom to hand board links to. They are also the one who obtains the participants' consent and tells them what is processed and why.
The service is a processor acting on the controller's instruction (part 3 of article 6 of Law No. 152-FZ). It stores and shows that data for exactly what the organiser entered it for — so that the board can show who leads a stage — and does not process it for its own purposes. The instruction itself is section 8 of the offer.

A participant who presses “that's me” supplies the name and photo from their own account: that is data they enter about themselves.

Leaving someone else's event works in two ways. The name and photo supplied by “that's me” are removed by the participant — profile, “Where I take part”, “unlink”. Anything the organiser typed about them is deleted by the organiser: the service does not edit someone else's event on the owner's behalf. If the organiser does not answer, write to the support address at the foot of any page.

What is collected when you write to support

The text of the message and the context shown on the form itself before you send it: the account e-mail, the event and your role in it, the browser string, the language, and the last lines of the event action log (the log is shown to the owner of the event only). The server also remembers the sender’s IP address — in process memory, until it restarts — to cap the number of messages per hour.

Cookies

pm.session_token — the organiser’s sign-in to the cabinet, 30 days.
pm_board_<event id> — the board sign-in: participation and role, 30 days.
pm_lang — the language of the cabinet, the board and the sign-in screens, one year.
pm_analytics — a mark that the visit-counter notice has been read, or the decision about the counter taken on the cookie page, one year.

There are no advertising cookies of the service's own, the service plugs in no ad network, and it hands visitor data to no one except the visit counter described below. On pominutam.ru the visit counter runs from the first visit, and a notice on the page says so. It can be declined on the cookie page: after a refusal its code never reaches the page and none of its new cookies appear in the browser. Neither the cabinet nor the board carries the counter. There is more in the Cookie Policy.

What this is for

The data serves exactly the thing a person came for: running an event to time. The programme and the scripts so the board can show what is on now; the log and the presence so the report can be assembled; the e-mail and, if one is set, the password so the organiser can come back to their account; support messages so they can be answered. The script text a person hands over for formatting or for filling blocks serves one purpose only — to turn it into a formatted script or an event programme; the AI assistance action accounting serves to count the plan quota. There is no advertising in the service and no selling of data.

Who the data goes to

The mail provider — sign-in links, letters confirming an address, resetting a password, reminding about account deletion, and support messages. The provider is set in the server configuration; while it is not configured, letters sit in a queue and go nowhere.
Telegram — a message to the author of the service about a new support request. It is not a “you have mail” ping: what goes to Telegram is the full text of the request, the sender’s e-mail and the whole context block — the account e-mail, the event title and address, the browser string, the language and the last five lines of the event action log. It is sent to api.telegram.org, so it leaves the service’s own server. If the bot is not configured, the message stays in the queue.
An S3-compatible file storage — photos of people only, and only if such storage is switched on in the configuration. By default photos live on the disk of the server itself. Where the storage physically stands is a matter of server configuration, so naming a country here would be untrue.
Yandex, for Yandex ID sign-in — only if the person chose this way to sign in themselves. The browser then goes to a Yandex page, and the person confirms the sign-in there. The service's server passes Yandex the one-time code Yandex returned to the browser and the keys of its application, and with the temporary access key it gets back reads the profile once. Yandex returns the name, the e-mail address, the account identifier and the identifier of the profile photo; if the profile has no photo of its own and the person has not removed it, the server uses it to download the photo from avatars.yandex.net with a separate request. The service does not keep the access key. No events, participants or photos are passed to Yandex in the process.
Yandex, for the visit counter — on the public pages of the site, until the person declines the counter on the cookie page. The browser talks to mc.yandex.ru directly, and what goes there is what any visited site sees: the IP address, the browser string (User-Agent) and device details, the addresses of the showcase pages opened and the address the person came from, plus the anonymised browser number the counter sets for itself. This is the data of a visitor to the public pages: no e-mail, no events, no participants and no photos are passed to the counter — the cabinet and the board carry no counter. After a refusal nothing is requested from the Yandex counter at all: the counter's code is not on the page.

The basis and the roles. On pominutam.ru the basis is the service's legitimate interest in knowing the attendance of its own public pages (art. 6(1)(7) of Federal Law 152-FZ): the counter counts visits, not behaviour — Webvisor, the click map and outbound-link tracking are off — it is not linked to account data, and the person may object at any time by declining on the cookie page. At addresses of the service outside the .ru zone the basis is the visitor's consent (art. 6(1)(1) of Federal Law 152-FZ), given in the banner; without it nothing is requested from the counter there at all. The roles are split the same way as with participants' data: the service is the operator (it decides what is counted and what for), Yandex is a processor acting on its instruction (art. 6(3) of Federal Law 152-FZ). The instruction is the Yandex.Metrica terms of use, which the service accepted by plugging the counter in; Yandex's own rules are in its privacy policy. The service cannot promise that Yandex makes no use of this data for its own purposes: that is outside its code, and such a promise would be untrue.
The model supplier — Yandex AI Studio (Yandex Cloud, Yandex.Cloud LLC) — and only once the organiser has pressed “Format script”, or “Fill blocks” on a script without block headings, themselves. What goes there is exactly what they wrote in the event script, plus the service instruction wrapped around that text. What ends up in that text is their own decision: it may carry the names, roles and job titles of participants, company names, talk topics — anything copied out of their own plan. No e-mail, no password, no photos, no programmes of other events and no action log are passed. The call goes to the supplier's servers in Russia; there is no cross-border transfer here.

The basis and the roles. The organiser passes their own data under the agreement with the service (offer, clause 4.3). Participants' data that ends up in the text is processed by the service on the organiser's instruction (section 8 of the offer), and to carry that instruction out the service engages the model supplier; by pressing the button the organiser instructs that transfer. The operator of this data remains the organiser, and it is for them to decide what details about participants to put into the script.

On training the models. Under the supplier's terms in force (“Terms of Use of the Yandex Foundation Models Service”, revision of 22.12.2025, clause 5.4.1) the information contained in requests may be used by Yandex and its affiliates for debugging and for training models — unless the client passes a special parameter forbidding such use. The service does pass that parameter. Every call to the model carries the documented header x-data-logging-enabled: false, by which the service asks for the request not to be stored; so what is in the script does not go into training the models.

This promise ends where the service's code ends. The service answers for the parameter going out with every request — and for nothing beyond that; it has no way of checking from its side how the supplier honours the request. The supplier's terms: yandex.ru/legal/cloud_terms_yandex_foundation_models; the parameter is described in the AI Studio documentation.

The transfer itself has not gone anywhere: the text still goes to the supplier's servers, only without being stored. What details about participants to send there remains the organiser's call.

There is no payment service on this list yet. Card payment is not switched on at the site: the service neither collects nor passes on any payment data. The settlement procedure is described in the offer; once payment works, a line will appear here about the e-mail address and the amount going to YooKassa, and about the cash receipt.

Nothing else leaves the service.

What other people can see

Photos are served from a direct link with no access check. The address is not guessable, but anyone who has it opens the photo without signing in, and the browser is allowed to keep it cached for a year. The same holds for external storage.
The stage script is visible to everyone holding the board link. There is no per-role filtering: the script travels in the board payload in full.
The owner of the service sees, in the maintenance panel, the account e-mails (of the first user of each) and the outgoing queue: channel, template, recipient address and failure code. The panel does not show letter bodies.

How long it is kept

Account data, events, programmes, people, checklists, reports and logs live as long as the account exists.
An account whose terms were never accepted (someone signed in by link or with Yandex ID and left the consent screen) is deleted after about a day: once it is older than a day, nobody has signed in to it during the last day and there is nothing in it — no events, no access to a plan, no other users.
Sent letters are removed from the queue 30 days after sending, together with the recipient address and the body. Unsent ones (for example, frozen after five failures) stay until they are dealt with by hand or until the account is deleted.
AI assistance action accounting records live as long as the account exists and are deleted together with it.
Account deletion is deferred: the button in the profile sets a seven-day term, and all that time the decision is cancelled by one button in the same place. When the term runs out, the user record itself is deleted, along with queued letters carrying their e-mail (including those where the e-mail sits inside the letter — a support request, for one) and the technical sign-in and password-recovery records.
The events, the people directory and the photos of the account are deleted only if no other users are left in that account. A shared account does not disappear with one of its people — otherwise one person leaving would take the others’ work with them.
Participation in other people’s events is detached on deletion: the organiser gets back what they typed in themselves (the name and short name from their directory), while the name and photo that “that’s me” had substituted are removed. The programme and the report of a past event stay as they were.
A photo is deleted once nothing references it any more, neither the directory nor a participation in an event.
The board cookie lives 30 days from sign-in; the attempt-limit counters live in process memory, until it restarts.

How to delete the data

The whole account — profile, “Delete account”. Seven days later everything listed above is gone, with the shared-account caveat.
One event of someone else — profile, the “Where I take part” section, “detach”. The link to the account is removed at once.
A whole event — the event’s “Report” screen, “Delete the event”. The programme, the scripts, the participants, the checklists, the log and the report go with it. The button is absent while the event is open or running: first “Finish the event”, and only then can it be deleted — otherwise deleting would pull the board out from under the participants mid-talk.
A single person or a photo — the “People” screen.
If something has to go and there is no button for it, write to support.