Article

Cybersecurity companies: get paid for your records

By TrustPast

Updated November 7, 2026

This page is for security companies: managed detection and response providers, security operations outsourcers, penetration testing and red-team firms, incident response shops, and the product companies that sell detection tools and run a support desk behind them. A firm like that with a few dozen people and a few years of operation keeps a record it rarely thinks about, because it is busy protecting everyone else’s.

That record is the triage. Every alert a security team has looked at, decided on and closed is a small, dated piece of reasoning: what it looked like, what was checked, why it was or wasn’t real. A buyer pays to license records like these to train AI models. It doesn’t want your clients’ networks. It wants the judgment your analysts applied to them.

The same idea runs through our page on what data buyers actually want from a trade business. A plumber’s job note that says what the leak turned out to be and an analyst’s ticket that says what the beacon turned out to be are the same kind of record. Here is what it looks like in a security company, what never leaves, and how it works with micro1.

The records a cybersecurity company keeps

These are our examples, not a buyer’s list. They are what a security company produces as it works, shift after shift, year after year.

The triage ticket. An alert fires. The analyst opens it, pulls the process tree, checks the reputation of a domain, looks at what else that host did in the last hour. Then a decision: benign, suspicious, escalate. The ticket keeps the steps and the verdict. A firm that has run a queue for five years has a very large number of these, and the closed-as-benign ones teach as much as the real incidents.

The escalation and the war room. When an alert turns out to be real, the work moves to a channel. The first hypothesis is often wrong. Someone notices the timestamps don’t line up. Someone else finds the initial access a week earlier than anyone thought. The channel is the diagnosis, written as it happened, with the dead ends left in.

The runbook. How to handle a phishing report. How to contain a host without tipping off the attacker. When to wake the client. Each runbook has versions, and each version came after a case where the old one didn’t work.

The detection tuning log. A rule is too noisy, so someone narrows it. Then it misses something, so someone widens it again. The tickets that record each change, with the false positives and the miss that prompted them, are a history of the team learning its environment.

The engagement work order. For a testing firm, the scoping call notes, the rules of engagement, the test plan, the daily status notes and the internal debrief. The final report usually belongs to the client. The way the firm planned, ran and reviewed the work is its own.

The shift handover. What is open, what is waiting on the client, what looked odd but wasn’t worth a ticket yet. Handover notes are short, and they capture what an experienced analyst thinks the next person needs to know.

The post-incident review. What happened, how it was found, how long each phase took, what would have caught it sooner, and what changes. Often written for the client and then rewritten for the internal team, with the internal version far more candid.

The product support queue. For a security vendor, the customer cases: a sensor that won’t deploy, a rule that blocks a legitimate business tool, a dashboard that shows the wrong count. The fixes and the workarounds sit in the tickets.

Two record types hold most of this. The tickets, the work orders and the engagement files are covered on our page on job files and work orders, which explains why the notes inside a closed job carry more than its status field. The war rooms and the analyst chatter are covered on our page on chat archives from Slack and Teams, including how far back an export reaches.

Together they show how an alert was triaged, how an intrusion was scoped, how a rule was tuned and how a test was planned. That is the how, not the who. The client’s name is never the point. The analyst’s reasoning is.

See your estimate

What counts, in micro1’s own words

micro1 says what it wants on its data partnerships page: “We are looking for data that reflects how work is actually performed within an organization.” It lists “standard operating procedures (SOPs), process documentation, internal knowledge bases, workflows, templates, operational frameworks, and other business process artifacts.” A security team’s runbooks are SOPs in the plainest sense.

It also says: “The most valuable datasets capture real operational expertise, decision-making processes, and repeatable workflows.” Triage is a repeatable workflow with a decision at the end of every run. Few businesses make as many recorded decisions per person per day.

micro1 lists industries whose operational data “can contribute”. It doesn’t name security. Two of its headings describe a security company’s day closely. Software & engineering: “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases.” And Customer support: “Support documentation, ticket workflows, QA processes, customer operations, and knowledge management.” A managed security provider is, among other things, a ticket workflow with very high stakes.

micro1’s October announcement explains why exceptions matter. It says: “Real business operations involve incomplete information, competing priorities and exceptions that require judgment.” An incident is all three at once: partial logs, a client who wants the server back up, and an attacker who didn’t follow the playbook.

On eligibility, micro1 says it wants “established companies with 30+ full-time employees, mature business operations, and substantial historical operational data,” naming “internal communications, SOPs, project histories, CRM records, support tickets, and other business documentation.” On volume: “There’s no fixed minimum number of files, documents, or terabytes.” It evaluates “the historical depth, breadth, quality, and relevance of the available data.”

What is never included

Start with people. Client employees’ names, email addresses, usernames, the victims named in a phishing case and anyone’s personal data in a log are not what a buyer wants. Our page on what is never included shows where personal details hide in a company’s files. In a security firm, they hide everywhere: in pasted log lines, in screenshots, in the subject of every phishing report.

Then the client’s own material. A security firm works inside other companies’ systems under contract. The final penetration test report, the client’s network diagrams, its asset inventory, the forensic images and anything the contract says belongs to the client stay with the client. Our page on client-owned work and NDAs covers how to read those terms before the scope is drawn. Ask counsel to read the master services agreements; they decide what is yours.

Some things never leave under any scope, as our own advice and not micro1’s. Credentials, keys, tokens and secrets recovered during an engagement. Malware samples and live exploit code. Details of vulnerabilities that haven’t been fixed or disclosed. Evidence held for a client’s legal matter. If a ticket contains any of these, it is set aside or the field is cut before anything moves.

A security firm also sees regulated data in passing: health records on a hospital’s file server, card data in a retailer’s logs. If your engagements touched those environments, read our page on health, payment and other regulated data, and ask counsel before any of those case files go near a scope.

What remains is still the larger part: your own runbooks, your own tuning history, your internal debriefs and the reasoning in your analysts’ threads.

How de-identification works

You don’t have to scrub the files yourself. micro1 says: “Does my company need to anonymize its data before transferring it? No, micro1 has processes for de-identifying and transforming sensitive information.”

micro1 publishes four confirmations it makes with the company “Before any participation”. De-identified before sharing, in micro1’s words: “Personal and identifying information is removed or transformed before your data is shared with third parties.” Data segregation: “Your data is kept separate from other companies’ data, with access restricted to authorized personnel.” Defined retention periods: “Raw data is deleted according to an agreed schedule.” And data is licensed “exclusively to labs and enterprises based in the U.S. and allied countries.”

On what happens to the records, micro1 says: “Depending on the nature of the data, personally identifiable information may be removed and certain datasets may undergo synthetic rewrites that preserve workflow structure while reducing direct ties to original records.” For a triage ticket, the structure is the point: the alert type, the checks made in order, the verdict. The hostnames and usernames are what a rewrite exists to change.

micro1 also says “access is restricted to a limited number of authorized team members,” that “employees with access to data systems use company-managed devices and follow established security controls and training requirements,” and that “companies have the opportunity to review representative samples before use.” A security company will want to test that sample harder than most. It should. Our page on how de-identification works covers what to look for.

One practical point, as our own advice: a security company usually knows which of its systems hold client artefacts and which hold its own process. Write that map down before the first call. It is most of the scope.

What decides the price

micro1 publishes its compensation tiers. “Qualified Enterprise Data Partnerships” are $100K-500K (indicative, not an offer). “Large-scale operational datasets or ongoing participation across multiple teams and business functions” are $500K-3M (indicative, not an offer). “Highly unique, proprietary operational data” is $3M+ (indicative, not an offer).

micro1 says compensation “is based on the quality, uniqueness, and value of the data provided.” Its FAQ names the factors: “dataset size and volume, workflow complexity, data quality, domain expertise represented, and the uniqueness of the operational knowledge contained within the dataset.” It also says “Each partnership is evaluated individually.”

Domain expertise is where a security company stands out. A senior analyst’s triage notes encode years of pattern recognition in a few lines. Workflow complexity is high too: an incident can run across detection, response, the client’s IT team, legal and leadership in a single day. Quality depends on habit. A queue where analysts wrote why they closed each ticket is worth more than one where they clicked “resolved” and moved on.

micro1’s payout page asks for the number of employees, the years of data and the headquarters country, and says the figure is an “Indicative estimate only. Final payout is determined based on data sources, volume, quality, access terms, and due diligence.” In our reading, what lowers it: a scope shrunk to almost nothing by client contracts, a ticketing system replaced without migration, chat with short retention. What raises it: years of annotated tickets, runbooks with their version history, and internal reviews that say what went wrong. Our page on what decides the price goes through each factor.

On payment, micro1 says it pays “in full within 30 days of acceptance.”

Which programme fits

micro1’s programme is for companies with 30 or more people, counted now or at peak, and for a company of any size outside the US. micro1 says it is “currently prioritizing US companies, followed by other Western markets.” Our estimate asks how many people work at the company, counting everyone including the night shift, and names the programme that fits that headcount. The line is explained on the programme page for 30 or more people.

Security companies get acquired and wound down like anyone else. micro1’s company referral page lists a “Defunct Company Data Partnership” and says: “We are acquiring data from companies that are no longer operating.” Its requirements are “30+ employees”, “10+ Countries”, “English” and “All industries”, with company compensation of “$100K-$3M+ for approved data packages” (indicative, not an offer). A closed security firm’s ticket archive and runbooks, if someone kept the export, fit that route. Who may sign for a company that no longer exists is a question for counsel.

Cybersecurity companies share the write-it-down-before-you-change-it discipline with semiconductor and materials companies, where a failed lot is diagnosed with the same patience as a breach. They share the triage habit with medical practices and health systems, where every case starts with symptoms and ends with a decision. And they share strict confidentiality around client data with investment firms, whose own reasoning is licensable while their clients’ details never are.

TrustPast

Questions and answers

Do our clients’ incident reports go to micro1?

Not as our advice. A report written for a client under contract is usually the client’s, and anything a client owns stays out. What a buyer wants, in micro1’s words, is “data that reflects how work is actually performed within an organization”: your own runbooks, tickets and triage threads.

Our tickets are full of hostnames, IP addresses and usernames. Is that a problem?

micro1 says personal and identifying information “is removed or transformed before your data is shared with third parties,” and that a company does not need to anonymize its data first. Credentials, keys and secrets found during work are a different matter: our advice is that they never leave, and the scope says so in writing.

Does micro1 want security companies specifically?

micro1’s pages don’t name the category. They list “Software & engineering” and “Customer support” among the operational data that can contribute, and both describe what a security operations team produces every day.

How is the price decided?

micro1 says compensation is based on “dataset size and volume, workflow complexity, data quality, domain expertise represented, and the uniqueness of the operational knowledge contained within the dataset.” Its published tiers start at $100K-500K (indicative, not an offer).

Can we see what is used before it is used?

micro1 says “companies are given the opportunity to review representative samples before prepared data is used.”

Do we have to be a certain size?

micro1’s published line is “30+ full-time employees,” with US companies prioritized “followed by other Western markets.” Under our one-buyer rule, a company outside the US goes to micro1 at any size.