Aggregated Information

Aggregated information is data combined from many individuals, devices or records into a summary: a total, an average, a count, a share or a trend. The result describes a group, not a person. A report showing how many tickets each team closed last week is aggregated; the list of individual tickets behind it is not.

Aggregation reduces detail, and it is often confused with anonymization. The two overlap but are not the same: aggregation changes the level at which data is shown, while anonymization is a claim that nobody can be identified. A summary can satisfy the first and fail the second.

Aggregation is a short pipeline, and its last step is the one teams skip. Unlike data masking, which hides values inside a record, aggregation drops the record as the unit of output altogether.

1. 1

   Collect

   Gather records from one or several sources, such as logs, forms or sensors.

2. 2

   Group

   Split the records by a chosen dimension: team, region, week or category.

3. 3

   Summarize

   Apply a function to each group: count, sum, average, minimum or maximum.

4. 4

   Suppress

   Hide or merge groups that are too small to protect the people inside them.

5. 5

   Review

   Check the output for combinations that point back to one person before sharing it.

Aggregates are everywhere because they answer management questions without exposing each case. Privacy law treats them with care: the CCPA, for example, excludes aggregate consumer information, meaning data about a group from which individual identities have been removed, from its definition of personal information. Analytics tools such as workforce analytics software rely on the same idea.

Aggregation has a second meaning in security, and it works in the opposite direction. Pieces of information that are harmless on their own can become sensitive once they are put together: a name, a job title, an office, and a travel calendar draw a picture that none of them draws alone. Security guidance describes this as an aggregation risk.

The practical consequence is that the classification of a summary is not automatically lower than the classification of its sources. A report that combines many sources can deserve the label of its most sensitive information, so whoever builds it should ask what it reveals as a whole, not only what each column contains.

Teams often assume that once records are summarized, privacy is solved. It is not, because summaries can leak through the way they are built:

Common safeguards are a minimum group size below which results are hidden or merged, rounding, and, in stricter settings, added statistical noise, known as differential privacy.

• Small groups: a team average computed over one or two people is almost a personal record
• Differencing: two reports that differ by a single person reveal that person's value
• Linkage: a summary combined with outside data can single someone out
• Outliers: the highest or lowest value in a group points to whoever holds it
• Repeated releases: a series of fine-grained summaries can be used to rebuild the original rows

The three terms describe different things, and mixing them up leads to wrong compliance claims. A tick in the third row means “can”, not “always”.

Much of what the console shows is aggregated. Dashboard widgets and reports in the Anexet Activity module give rankings, shares, and trends for productivity and work-time monitoring instead of a feed of single events. The first view groups incidents by risk level; the second is the setup of a widget that ranks users by a chosen metric.

1 / 2

• 
• 

Decide the smallest group your reports may describe and write it down, then check every new dashboard or export against that rule. Keep the source records under the same protection as the summaries built from them, and label a summary by what it could reveal when combined with others, not by how harmless it looks alone.

Aggregation is a good default when results are shared widely. It is a design choice that needs a rule behind it, not a guarantee.