SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Breaches and Incidents

DTU deletes former users' addresses after six months, not their CPR numbers, and holds about 160,000 of them

DTU says unauthorised persons used compromised DTU profiles to reach its identity database and download a large amount of data, and that it cannot say what or how many. For the roughly 160,000 former users, it says, six-month deletion spares CPR numbers and full names.

By Parminder Kumar Sharma · · 21 min read

A dim university office at dusk: a laptop on a wooden desk shows a directory list made only of blank rounded rows, beside a blank staff badge on a lanyard, with a brick campus building lit in the window behind. The headline reads DTU deletes former users' addresses after six months, but not their CPR numbers, with the figure 160,000.

40,000 plus 160,000 is 200,000, and four in five are former users

The Technical University of Denmark (DTU) says its identity database, DTUBasen, holds records on about 40,000 active users and about 160,000 former users, and that information on up to 200,000 current and former users may have been affected. DTU gives all three figures and they agree: 40,000 plus 160,000 is 200,000. The share is ours: 160,000 of 200,000 is 80 per cent, so four in every five people in the count have left DTU. The records reach back to 2003, 23 years before the notice of Friday 2 October 2026 (our arithmetic: 2026 minus 2003).

That sum matters because of one sentence in the notice. For former users, DTU says, home addresses, profile pictures and information about next of kin are automatically deleted after six months. It then adds: "DTUBasen continues to contain information including CPR numbers and full names." The CPR number is the Danish civil registration number. So the deletion rule covers three fields, and the identifier is not one of them. That does not mean all 160,000 have a CPR number on file, because DTU says it holds them for only a small number of guests and external partners. Against records up to about 23 years old, six months is one forty-sixth of the span (276 months divided by 6, our arithmetic).

What that does not establish is most of what a headline would claim. It does not show that 200,000 people were exposed: the figure is a ceiling, "up to", and DTU says it is "not possible to determine precisely what information was downloaded or how many people have been affected". It does not show that former users' CPR numbers were in the download, only that they were in the database. It does not say when access began or was found, how the accounts were compromised, whether a second factor applied, or who was behind it. It does not say which authorities are investigating, or name the police. And it does not say how many people will receive the letter that DTU says will go by e-Boks, a Danish secure digital mailbox that public bodies use to write to residents.

The BleepingComputer report that prompted this briefing is a pointer, and it differs from the notice in three places. It says the attacker "used compromised credentials". The notice says unauthorised persons compromised "DTU profiles" and never uses the word credentials. BleepingComputer says DTU will not notify all students; the notice says "almost all" current and former students for whom DTU holds a CPR number will be notified, and puts the gap in guests, external partners and next of kin. And BleepingComputer repeats the six-month deletion without the sentence that CPR numbers and full names remain, which is the sentence this briefing is about. Where the report and the notice differ, it follows the notice.

The retention picture, drawn from the notice

The diagram sets the notice's retention sentence beside its field list. Everything in it is DTU's wording or our arithmetic, and where the notice is silent the cell says so.

A bar to scale shows about 40,000 active users (20 per cent) and about 160,000 former users (80 per cent) in DTUBasen. A table lists fields. For former users, the notice says home address, picture and next of kin are deleted after six months, while CPR numbers (where DTU holds one) and full names are still held. Work details and any other fields are not stated. A band lists what the notice does not say.
Drawn from DTU's notice of 2 October 2026, English and Danish versions. Counts are DTU's approximations; the shares and the not stated cells are ours.

Two rows do the work. The notice says nothing about work details for former users, such as work email, job title and office location, so whether those are deleted, kept or were in the download is not stated. And the Danish text introduces the active-user list with "blandt andet", among other things, so even the fields it names are not a promise that the list is complete.

The record, with times

Dates and times on the public record, converted to UK time where the source uses another zone. DTU's notice gives no time, and no date other than 2 October.

  1. When
    Mon 21 Sept 2026
    What the record says
    Datatilsynet received DTU's breach notification, according to its reply to TV 2. DTU's own notice gives no date for the filing.
    Basis
    TV 2, 2 October. Secondary, single source.
  2. When
    Fri 2 Oct 2026, 08:28:58 BST (09:28:58 CEST)
    What the record says
    DTU's press release is distributed through Ritzau's press service.
    Basis
    Ritzau page timestamp. DTU's own release.
  3. When
    Sat 3 Oct 2026, 15:35 BST (10:35 EDT)
    What the record says
    BleepingComputer publishes its report.
    Basis
    Page metadata. Secondary.
  4. When
    Sat 3 Oct 2026, 21:00 BST
    What the record says
    DTU's English and Danish pages, read in full, are still dated Friday 2 October and carry no update note. DTU says it will update the page when significant new information becomes available.
    Basis
    Our reading of the pages.
  5. When
    Not on the record
    What the record says
    When the intrusion began, when it was found, how long the attacker had access, when DTU became aware, and when the e-Boks letters go out.
    Basis
    DTU's notice is silent.

The only dated fact before 2 October is 21 September, and it rests on one outlet's report of what Datatilsynet said. If it holds, the interval from the report to the regulator to the public notice is 11 days (Monday 21 September to Friday 2 October, our arithmetic). The notice itself dates nothing earlier.

What is stated, and what is not

Questions a reader would ask, checked against DTU's English and Danish notices and DTU's own IT pages. Quotation marks show the notice's wording. As of 21:00 BST on 3 October 2026.

  1. Question
    What system?
    Stated
    DTUBasen, DTU's identity and access management system. DTU's IT page says it manages core information about employees, students and temporarily affiliated individuals, and that other systems rely on it.
    Not stated
    Product, vendor or version. Which of the systems that rely on it, if any, were reached.
  2. Question
    How did they get in?
    Stated
    "Unauthorised persons compromising DTU profiles and using them to gain access to DTUBasen", in "a targeted cyberattack".
    Not stated
    How the profiles were compromised, how many, whether any were privileged, whether multi-factor authentication applied. The word credentials is BleepingComputer's, not the notice's.
  3. Question
    When?
    Stated
    Notice dated Friday 2 October 2026. Data in the system goes back to 2003.
    Not stated
    When access began, when it was found, how long it lasted, when DTU became aware.
  4. Question
    What was taken?
    Stated
    "A large amount of data" was downloaded. DTU cannot determine what information was downloaded or how many people are affected.
    Not stated
    Which fields, how many records, and whether former users' CPR numbers were in it.
  5. Question
    How many people?
    Stated
    Up to 200,000: about 40,000 active and about 160,000 former users.
    Not stated
    The number actually affected, and its split between active and former users.
  6. Question
    Who?
    Stated
    "Unauthorised persons". The attack is called targeted.
    Not stated
    Identity, motive, any claim of responsibility, extortion or publication. None is reported in the coverage read, as of 3 October.
  7. Question
    Police?
    Stated
    The case was "referred to the relevant authorities for further investigation", and DTU says its own investigations and the authorities' continue.
    Not stated
    That the police are the authority, or which body is. No source names one.
  8. Question
    Regulator?
    Stated
    Reported to Datatilsynet, the Danish Data Protection Agency.
    Not stated
    The date, in the notice. TV 2 reports Datatilsynet received it on 21 September.
  9. Question
    Contained?
    Stated
    DTU's IT incident response team "has contained the attack".
    Not stated
    When, how, and whether other systems were touched.
  10. Question
    Who is told, and how?
    Stated
    Current and former employees, and "almost all" current and former students for whom DTU holds a CPR number, by e-Boks, "as soon as possible". A public notice for everyone else.
    Not stated
    When the letters go, what they say, how guests, partners and next of kin are reached beyond the web page, and how people now abroad are reached.

A directory is a data store, and a deletion rule covers fields, not records

The notice calls DTUBasen an identity and access management system, and the label does a lot of work. It sounds like a gate: a thing that decides who may log in. DTU's own IT pages show a directory. DTUBasen manages core information about employees, students and temporarily affiliated individuals. People are asked to keep their job title, profile picture, DTU address, work phone number, private address and emergency contacts up to date there. The legal full name stays because bookings such as hotels and flights need it. Local DTUBasen administrators, listed inside the system, make some changes for users. The same pages say an employee with special IT privileges should have a separate account for them. The gate is one use of the directory. The directory is also a store of personal data, and a login into it is a data breach in itself.

That last point is not our opinion. The ICO's guide defines a personal data breach to include unauthorised access to personal data, and Datatilsynet's guidance works the case of a hacker who gets in when it cannot be determined whether anything was downloaded: still a breach of confidentiality. The NCSC's identity guidance, published on 22 January 2018, says "the identity system itself will be of interest to attackers".

Phrases in the notice and the coverage, and what each leaves out. Wording is as quoted from DTU's English notice unless marked.

  1. Phrase, and who used it
    "Identity and access management system" (DTU)
    What it covers
    The role: logins and permissions.
    What it leaves out
    That it is also a store of personal data: CPR number, name, address, picture, next of kin, work details. A login into it is a breach on its own.
  2. Phrase, and who used it
    "Automatically deleted after six months" (DTU)
    What it covers
    Home address, profile picture and next of kin of former users.
    What it leaves out
    The record. DTU says CPR numbers and full names remain. Work details of former users are not mentioned.
  3. Phrase, and who used it
    "Compromised DTU profiles" (DTU) and "compromised credentials" (BleepingComputer)
    What it covers
    Accounts were misused to reach the database.
    What it leaves out
    The notice's word is profiles, plural. How, how many, whether any were privileged and whether MFA applied are not stated.
  4. Phrase, and who used it
    "Almost all current and former students" (DTU) against "not all" (BleepingComputer)
    What it covers
    Most students whose CPR number DTU holds will get a letter.
    What it leaves out
    Who the remainder are. The notice puts the CPR gap in guests, partners and next of kin.

Why the CPR number is the field to watch

A CPR number has ten digits. The CPR office, which runs the register, says the first six are the day, month and year of birth without the century, the last four are a serial number, and the tenth digit indicates sex. So the number carries a birth date. Datatilsynet says public authorities may process it to identify a person uniquely, and that private bodies may do so only in listed cases. DTU itself says CPR numbers in the wrong hands could be used for identity fraud and could make phishing more convincing. Its advice includes a credit alert on the number at Borger.dk, which the Sikkerdigital.dk site that DTU links to describes as a signal to banks and firms to check identity more carefully before lending; it is voluntary for them to look.

The nearest UK counterpart is the National Insurance number, with a difference. GOV.UK describes it as two letters, six numbers and a final letter, the same for life, and says not to share it "with anyone who does not need it". Its description includes no birth date; a CPR number has one built in, which is one more reason to ask what a leaver's record needs to contain.

Retention and notification meet at the same field. DTU says it will write to current and former employees and almost all students for whom it holds a CPR number through e-Boks. E-Boks is a Danish secure digital mailbox. Public bodies write to residents who have a CPR number through the state's Digital Post, which residents are obliged to read and can read in e-Boks, one of four places to do so. DTU holds CPR numbers for only a small number of guests and external partners and none for next of kin, and says it cannot contact them directly, so they get a public web page instead. The notice does not say that the CPR number is the address for an e-Boks letter, but it reads that way, and that is our inference. If it is right, the field that makes this breach serious is also DTU's only route to tell former students about it. For a UK reader, a letter in e-Boks is closer to a statutory inbox than to email. How a former student now living abroad is reached, the notice does not say.

The clocks: 72 hours to the regulator, no fixed count for people

The clocks in EU and UK GDPR Articles 33 and 34 (EUR-Lex, legislation.gov.uk), Datatilsynet's guidance of May 2025 and the ICO's breach guide. What is public for DTU is from the notice and TV 2.

  1. Clock
    Tell the regulator
    What the rule says
    Article 33(1): "without undue delay and, where feasible, not later than 72 hours after having become aware of it". Datatilsynet counts calendar hours, so weekends count, and information can follow in phases. UK GDPR Article 33 has the same text, now naming the Commission.
    Public for DTU
    Reported to Datatilsynet. The notice gives no date. TV 2 reports 21 September.
  2. Clock
    Tell the people affected
    What the rule says
    Article 34(1): "without undue delay" when the breach is likely to cause a high risk. No day count. Datatilsynet says where hackers hold the data this should come approximately immediately after the breach is established, directly and in writing, and that a press release alone is typically not enough. Article 34(3)(c) allows a public communication where direct notice is a disproportionate effort.
    Public for DTU
    e-Boks letters "as soon as possible", in the future tense on 2 October. A public notice for people DTU cannot reach. The date letters go out is not stated.
  3. Clock
    Police and other authorities
    What the rule says
    Not part of Articles 33 or 34. Datatilsynet accepts that stopping a breach, or working with the police or Styrelsen for Samfundssikkerhed, a Danish state agency, can justify some delay.
    Public for DTU
    "Relevant authorities". No body named.

Two intervals can be derived, and neither is a finding of lateness. From Monday 21 September to Friday 2 October is 11 days, if TV 2's report of Datatilsynet's reply is right. And if DTU's filing met the 72-hour rule, DTU became aware no earlier than about 18 September, which is a deduction from the rule and not a date DTU has given. Datatilsynet's guidance accepts that containing an attack or working with the police can justify some delay, and the notice does not say when DTU became aware, what it knew on which day, or why the public page came first and the letters are "as soon as possible". That interval is a question for Datatilsynet, which holds the filing.

For a UK team the rules are the same under different names. UK GDPR Article 33 is word for word the same, with the regulator written as the Commission. From 30 September 2026 the office of Information Commissioner is abolished and its functions pass to the Information Commission (S.I. 2026/1015, made 10 September). The ICO pages we read on 3 October still use the ICO name, and two of them carry a banner saying the guidance is under review after the Data (Use and Access) Act. Its breach guide has an example that fits this case: you find an intrusion in which files were accessed, and you do not know how the attacker got in or whether the data was copied. You notify within 72 hours, say what you do not yet know, and send more as you find it. "We cannot say what was downloaded" is a reason to say so early, not a reason to wait.

Two earlier briefings measured neighbouring intervals the same way: the Pentagon's breach letter, dated 64 days after discovery, and the difference between the 72 hour clock to a regulator and what the public is told.

Retention decides how big the next breach is

UK GDPR Article 5(1)(c) asks that personal data be "adequate, relevant and limited to what is necessary". Article 5(1)(e) asks that it be kept in identifiable form "for no longer than is necessary" for its purposes. The ICO says the law sets no fixed period, that you must be able to justify the one you choose, and that you should not keep data indefinitely "just in case". These are the text and guidance as read on legislation.gov.uk and ico.org.uk on 3 October 2026; the ICO's page notes it is under review.

DTU's six-month rule is a retention rule, and it is evidence that someone thought about the problem: three personal fields go automatically. The gap is the field it leaves. The notice does not say why a former user's CPR number and full name need to stay in the live directory. Reasons an organisation might give include matching a returning student to an old record or confirming an award. We do not know that these are DTU's reasons, and each of them is a purpose for a minimal archive record, not obviously for a live directory that other systems read.

UK universities already draw one line. One UK university's student-records schedule, built on a Jisc model and dated December 2016, keeps the digital module profile, final transcript and pass-list data permanently, citing the university's duty to provide proof of qualifications, and sets hard copy student records at six years after the relationship ends. It predates UK GDPR and cites the Data Protection Act 1998, so it is an illustration of the reasoning and not a statement of current compliance. It shows that "keep a minimal record for ever" has a precedent and "keep everything for ever" does not. What counts as minimal is the decision, and it is rarely written down for the identity system. A decade-old access path in another briefing is a reminder of how long arrangements outlive the decision that made them.

The UK angle: the same kind of directory

UK universities, colleges and large employers run a directory fed by HR and student records, trusted by other systems for access, holding names, photographs, contact details and, wherever people can record them, emergency contacts. The shape of this incident is general: a login into a shared directory, a retention rule that covers some fields, and a letter to people who left long ago.

DTU's public notice is also a decent template for the letter you would have to write. It lists the fields, states the consequences (identity fraud and more convincing phishing), says what DTU is doing and gives people things to do: be alert to messages that seem to know their DTU connection, do not approve unexpected login or authentication requests, change a reused DTU password, and consider a credit alert. The ICO's guide asks for the same elements: a contact point, the likely consequences, the measures taken, and advice such as a password reset and watching for phishing.

On the administrator question, the UK government's survey of businesses asked how confident the person responsible was at controlling who has admin rights, and 9 per cent were not confident in the 2026 report. As our briefing on it explains, that measures one person's confidence and not whether the control is on, so it cannot tell you about your directory. An incident where stolen staff passwords opened two portals with no second factor is in our briefing on the French tax authority. DTU's own page says many of its systems require multi-factor authentication. It does not say which, and the notice does not say whether the compromised profiles were covered.

What to do, in the order worth doing it

Take this with you

Actions, in order

  • List every system that works as a directory of people: the identity provider, any on-premises directory, the HR and student-record feeds into it, guest and visitor accounts, alumni and contractor records. For each, write down the fields it holds and which of them are personal data.
  • Find out what happens to each field when someone leaves. Test it with a real leaver from last month and one from 2005, and write down whether the record is deleted or only some fields are.
  • Take national identifiers out of the shared directory: National Insurance numbers, passport or visa numbers if stored, date of birth, home address and next of kin. If a payroll or student system needs them, keep them there, behind tighter access, not in the directory that other systems read.
  • List every account that can read the whole directory: administrators, local or delegated administrators, service accounts and scripts. Remove standing access where you can, give administrators separate accounts for privileged work, and name an owner for each service account.
  • Require phishing-resistant multi-factor authentication on the administrator console and on any account that can read or export the directory in bulk. Then check every route in, not just the main portal, including legacy sign-in routes and alternative identity providers.
  • Alert on bulk reads and exports from the directory, such as a full listing or an unusual number of queries from one account. Test that the alert fires and that a named person receives it.
  • Make accessed or downloaded a question your logs can answer. Keep directory read and export logs for longer than your slowest detection time. Datatilsynet's guidance says a controller that cannot tell whether data reached others should start from the worst case.
  • Pre-write the breach notice for someone who left in 2005: the fields held, the likely consequences, what you are doing, a named contact and the advice. Decide the channel now, because an email address from 2005 will probably not work, and note who has no address you hold.
  • Set a number for how long leaver attributes stay in the live directory, write down the purpose for anything kept longer, and run a job that enforces it and that you can show running. Article 5(2) asks you to be able to demonstrate compliance.
  • Ask any supplier that hosts your directory or identity service how long it keeps sign-in and read logs and how fast it must tell you of unauthorised access. Article 33(2) already requires a processor to tell you without undue delay.

Method and interest

DTU is the body that suffered the breach, and its notice is its own account, with its own interest in the framing. It is also unusually specific: it says which fields are deleted and which remain, it says it cannot tell what was downloaded, and it states the part that reflects least well on its retention, that CPR numbers remain for former users. The notice names one person, University Director Bjarke Bak Christensen, who is quoted in it. No one else is named here, and nothing here speculates about who attacked DTU.

TV 2's report that Datatilsynet received the notification on 21 September is the only source for that date. TV 2 says it asked Datatilsynet, which said it is working on the case and had no further comment. The Datatilsynet pages we read publish guidance and a reporting form, and we found no case page for DTU, so we could not confirm the date from the regulator. BleepingComputer is a secondary source and a pointer; where it differs from the notice we follow the notice and say so. DKCERT republished the release and lists DTU's company number, so it adds no independence. We have no commercial interest in the story.

Things that could be overtaken within the hour, as of 21:00 BST on 3 October 2026: DTU's pages carry no update after Friday 2 October; no claim of responsibility, extortion demand or publication of data appears in the coverage we read, and we did not search criminal forums or leak sites; and the e-Boks letters are described as forthcoming. We could not read DTUBasen's user guide, because its web address did not respond to our requests that evening, and we draw no conclusion from that. The administrator page on DTU Inside asks for a DTU login, which we did not try to pass.

The question that exposes the gap

If one ordinary account were used tonight to download everything your directory lets it read, which of the people who left your organisation in 2005 would be in it, with which national identifier, and how would you reach them to say so?

Key facts

Sources

  1. PrimaryDTU's notice of Friday 2 October 2026, English version, read in full: DTUBasen, compromised DTU profiles, up to 200,000 users, the six-month deletion and the sentence that CPR numbers and full names remain, notification by e-BoksTechnical University of Denmark (DTU)accessed 2026-10-03
  2. PrimaryDTU's notice, Danish version, read in full and compared with the English: same content; the Danish list of active-user fields is introduced with blandt andet, among other thingsTechnical University of Denmark (DTU)accessed 2026-10-03
  3. PrimaryDTU's IT-information page, which carries the notice and says it will be updated as significant new information becomes availableTechnical University of Denmark (DTU)accessed 2026-10-03
  4. PrimaryThe same release as distributed, stamped 2 October 2026 09:28:58 CEST, used for the time of publicationRitzau press service (DTU's release)accessed 2026-10-03
  5. PrimaryDTU Inside page on DTUBasen, updated 18 November 2025: what the identity database manages, the fields users maintain, local administrators, separate accounts for special IT privilegesTechnical University of Denmark (DTU)accessed 2026-10-03
  6. PrimaryDTU Inside page on multi-factor authentication, updated 11 September 2025: many of DTU's systems require MFA; it does not say whichTechnical University of Denmark (DTU)accessed 2026-10-03
  7. PrimaryGuidance on handling personal data breaches, May 2025, read in full: 72 hours, when a controller is aware, phased notification, notifying individuals, hacker examples, press releases and direct noticeDatatilsynet (Danish Data Protection Agency)accessed 2026-10-03
  8. PrimaryHow to report a breach to Datatilsynet through Virk.dk, and the 72-hour ruleDatatilsynet (Danish Data Protection Agency)accessed 2026-10-03
  9. PrimaryThe rules for processing CPR numbers: public authorities for unique identification, private bodies only in listed casesDatatilsynet (Danish Data Protection Agency)accessed 2026-10-03
  10. PrimaryRegulation (EU) 2016/679 (GDPR), Articles 33 and 34 read in the official textEUR-Lex, Publications Office of the EUaccessed 2026-10-03
  11. PrimaryUK GDPR Article 33 as in force on 3 October 2026, naming the Commission from 30 September 2026legislation.gov.ukaccessed 2026-10-03
  12. PrimaryUK GDPR Article 34, communication of a breach to the data subjectlegislation.gov.ukaccessed 2026-10-03
  13. PrimaryUK GDPR Article 5(1)(c) data minimisation and 5(1)(e) storage limitation, and Article 5(2)legislation.gov.ukaccessed 2026-10-03
  14. PrimaryS.I. 2026/1015, made 10 September 2026: abolition of the Information Commissioner and transfer of functions to the Information Commission on 30 September 2026legislation.gov.ukaccessed 2026-10-03
  15. PrimaryPersonal data breaches: a guide, read in full: the 72-hour duty, the worked example of an intrusion where copying is unknown, what to tell individualsInformation Commissioner's Officeaccessed 2026-10-03
  16. PrimaryPrinciple (e), storage limitation: no fixed periods, justify the period, do not keep data indefinitely just in caseInformation Commissioner's Officeaccessed 2026-10-03
  17. PrimaryIntroduction to identity and access management, published 22 January 2018: the identity system is itself a target, privileged accounts, monitoringNational Cyber Security Centreaccessed 2026-10-03
  18. PrimaryHow a CPR number is built: birth date in the first six digits, serial number, tenth digit indicates sexCPR-kontoret (Danish civil registration office)accessed 2026-10-03
  19. PrimaryWhat Digital Post is and where it is read, including e-Boks: public bodies write to residents with a CPR number, who are obliged to read itDanish government (lifeindenmark.dk)accessed 2026-10-03
  20. PrimaryWhat a credit alert on a CPR number is and that checking it is voluntary for banks and firmsSikkerdigital.dk (linked from DTU's notice)accessed 2026-10-03
  21. PrimaryThe National Insurance number: format, same for life, do not share with anyone who does not need itGOV.UKaccessed 2026-10-03
  22. PrimaryStudent Records Retention Schedule, version 7, December 2016, built on a Jisc model: digital module profile, final transcript and pass list kept permanently, hard copy records six years after the relationship endsUniversity of Westminsteraccessed 2026-10-03
  23. Reported byReport of 2 October 2026 that Datatilsynet told TV 2 it received DTU's notification on 21 September; the only source for that dateTV 2accessed 2026-10-03
  24. Reported byFull republication of DTU's Danish release at 10:25 on 2 October; its footer lists DTU's company number, so it is not independentDKCERTaccessed 2026-10-03
  25. Reported byReport of 3 October 2026 that prompted this briefing, used as a pointer; it says compromised credentials and omits that CPR numbers remain for former usersBleepingComputeraccessed 2026-10-03

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.