Can AI Find Cyber Threats Hiding on the Dark Web?

Cyber criminals discuss companies, sell stolen credentials, advertise network access and publish stolen data across underground forums, marketplaces and ransomware leak sites. Security services already monitor these sources, but the volume of information creates a persistent problem.

A company name may appear in irrelevant conversations, duplicated breach lists, old credentials, fake claims, recycled data, legitimate references, criminal planning or stolen access advertisements. Separating meaningful intelligence from noise has always required significant human effort.

Google has introduced a Gemini-powered dark-web intelligence capability within Google Threat Intelligence. According to Google’s documentation, the service is designed to understand an organisation’s business context and identify the dark-web information most relevant to it, rather than relying solely on simple keyword matching.

Last checked: 29 July 2026.

What dark-web monitoring actually means

“The dark web” is a term used loosely to describe a range of criminal sources that are not indexed by standard search engines. These include: Tor hidden services, invitation-only criminal forums, underground marketplaces, ransomware leak sites, criminal messaging channels (such as Telegram groups), paste sites, credential marketplaces, stealer-log services, publicly indexed breach databases, closed communities, and ordinary websites hosting stolen data.

No commercial monitoring service can guarantee access to every forum, private group, encrypted conversation, marketplace, newly created site, temporary leak or direct criminal communication. Coverage varies between providers and changes continuously as criminal infrastructure is created, abandoned, migrated and shut down.

The value of monitoring depends on which sources a provider can access, how recently data was collected, how accurately findings are attributed, and how quickly relevant intelligence reaches the people who need to act on it.

What Google has launched

Google has introduced a dark-web intelligence capability within Google Threat Intelligence, a platform that consolidates threat data from Google’s own intelligence operations, including those from Mandiant and VirusTotal. According to current documentation, the new capability uses Gemini to help security teams understand which dark-web findings may be relevant to their specific organisation.

Google says the service is designed to: build an organisational profile using business context; continuously monitor dark-web sources; compare findings with that organisational context; identify potential relationships between criminal activity and the organisation; prioritise relevant findings; and provide contextual explanations of why an item may matter.

According to Google’s announcements, the capability is available through Google Threat Intelligence and is intended for organisational security teams. As of the date of this article, Google has described the dark-web intelligence features as being in public preview. Availability may depend on licensing, geography and account type. Organisations should consult current Google Cloud documentation or their Google account representative for precise access requirements.

Google Threat Intelligence draws on data from Mandiant, VirusTotal and Google’s own threat research. Each brings different coverage: Mandiant provides incident response and intelligence expertise; VirusTotal aggregates file, URL and threat data from many sources; Google’s own teams monitor global threats. The new dark-web capability sits within this wider platform rather than operating as a separate standalone product.

Not the old Google Dark Web Report

If you previously used the consumer Dark Web Report to monitor personal details associated with your Gmail account, that service no longer operates. Current monitoring options for personal information include third-party identity-protection services and breach-monitoring platforms such as Have I Been Pwned.

How Gemini changes the process

Traditional dark-web monitoring typically works as follows: an organisation supplies keywords such as its domain name, brand name, executive names or email addresses; the monitoring service searches collected dark-web data for those terms; matching items generate alerts; and analysts then determine whether the results are actually relevant.

This approach has limitations. Common names produce many irrelevant matches. Criminals may avoid mentioning a company directly. Old datasets are repeatedly recycled. Alert volumes can become unmanageable.

According to Google’s documentation, the Gemini-assisted approach works differently: Gemini builds an organisational profile containing relevant business context; dark-web information is compared against that context rather than against simple keyword lists; potential relationships between external activity and the organisation are identified; findings are prioritised by relevance; and the system provides an explanation of why a particular item may matter.

Business context that an organisational profile may include: legal company names, trading names, domains, email domains, subsidiaries, brands, products, executives, suppliers, technology platforms, office locations and acquired businesses. Only the specific fields included in Google’s current implementation should be assumed; any additional elements should be verified against current documentation.

A human analyst remains responsible for validating any finding before an organisation responds. AI-generated prioritisation is a tool for analysts, not a substitute for them.

Why keyword monitoring creates noise

Alert fatigue is a genuine problem in security monitoring. When too many alerts arrive, or too many are irrelevant, real threats can be overlooked.

Common sources of irrelevant alerts in keyword-based monitoring include: common company names appearing in unrelated discussions; brand names that are ordinary words; similarly named organisations; old breach databases containing credentials that have already been changed; duplicated datasets that have been sold multiple times; recycled credentials from historic incidents; fake criminal advertisements used to attract buyers; scraped public data that includes company mentions; expired domains still appearing in old datasets; former employees whose accounts no longer exist; and test accounts that were never decommissioned.

Poor-quality monitoring can result in genuine threats being overlooked among the noise, time being wasted investigating irrelevant results, already-secured accounts being unnecessarily reset, unnecessary concern for employees and customers, unclear ownership of the investigation process, and no measurable improvement in security posture.

What the service may look for

Based on the types of threat intelligence that Google Threat Intelligence covers and the documented capabilities of the dark-web monitoring service, potential categories of dark-web intelligence include:

• Employee credentials offered for sale in criminal marketplaces
• Email addresses or usernames appearing in breach datasets
• Malware information-stealer logs containing business account credentials
• Network access to the organisation being advertised by initial-access brokers
• Company data published by a ransomware group on a leak site
• Leaked source code from internal systems
• Confidential documents or contracts
• API keys or cloud tokens
• Remote-access credentials including VPN accounts
• Session cookies or authentication tokens
• Brand impersonation or phishing infrastructure
• Threat-actor discussions mentioning the organisation
• Evidence of a supplier compromise that may affect the organisation

These represent potential categories of intelligence rather than a confirmed list of guaranteed features. The specific capabilities included in the current version of Google’s dark-web monitoring should be verified against current official documentation before assuming any particular category is covered.

Dark-web monitoring versus breach monitoring

Breach monitoring and dark-web threat intelligence overlap but are not the same.

Breach monitoring typically looks for known exposed personal information: email addresses, usernames, passwords, phone numbers and other personal data that has appeared in known public or semi-public breach datasets. Services such as Have I Been Pwned provide breach monitoring for email addresses.

Dark-web threat intelligence may also look for attack planning, advertised network access, data-sale discussions, ransomware claims, source-code exposure, supplier relationships, threat-actor behaviour and references that require interpretation to connect to a specific organisation.

What an alert can and cannot prove

A dark-web alert may indicate one or more of the following: credentials were previously exposed in an incident; data appears in a criminal dataset; a threat actor claims to have access; a company name or related identifier is being discussed; stolen information may be available for purchase; or a supplier incident may be affecting the organisation.

A dark-web alert does not automatically prove: that the credentials still work; that the data is authentic; that the breach is recent; that the company network is currently compromised; that the threat actor is telling the truth; that ransomware is imminent; that every listed person is at risk; or that the monitoring platform has complete context.

What to do when credentials are found

A structured response is more effective than an immediate reaction. The following sequence applies whether the alert comes from Google Threat Intelligence or any other monitoring service.

1. 1Validate the account: confirm the username, domain, account owner, whether the account still exists, whether it is personal, business or shared, and whether the alert is current
2. 2Reset the password: require a unique password that has not been used before — do not simply add a number to the old one
3. 3Revoke active sessions: where supported, invalidate refresh tokens, browser sessions, app passwords, remembered devices and VPN sessions
4. 4Confirm MFA: verify that multi-factor authentication is in place and that no unknown authentication methods have been added
5. 5Review sign-in activity: look for unfamiliar locations, impossible travel, failed attempts, unusual devices, legacy authentication, new email-forwarding rules, suspicious OAuth consent, mailbox delegation and new MFA methods
6. 6Check password reuse: determine whether the exposed password was also used on other business or personal accounts
7. 7Review the device: if an information-stealing malware may have captured the credential, changing the password on the infected device may expose the new password immediately
8. 8Document the response: record the alert, validation steps, actions taken, the person responsible, evidence retained, outcome and next review date

When company data is found

If an alert indicates that company data has appeared on a criminal source, a controlled response is required.

• Preserve the alert evidence without casually downloading suspicious files from criminal sources
• Validate whether the data genuinely belongs to the organisation
• Determine the sensitivity of the data: customer records, employee information, financial data, contracts, intellectual property, emails, source code, credentials, access tokens, backups, database exports or identity documents
• Establish whether the data is already publicly available or genuinely criminal in origin
• Identify the likely source of the exposure
• Determine which systems, accounts or people may be affected
• Inform the incident-response lead immediately
• Involve legal or data-protection advisers where appropriate
• Review regulatory notification duties — the ICO must be informed of personal-data breaches meeting the reporting threshold within 72 hours of awareness
• Contact cyber insurers where the policy or terms require notification
• Avoid contacting criminals or negotiating without specialist legal and cyber-security advice
• Avoid making public statements prematurely

Initial-access brokers

An initial-access broker is a criminal who obtains access to an organisation’s systems and sells that access to other criminals, typically ransomware groups or other threat actors. Advertisements for initial access often appear on underground forums and may describe the target in general terms rather than naming the company directly.

An advertisement may mention: the industry sector, country, approximate revenue, number of endpoints, security products in use, type of access available (domain administrator, VPN, remote desktop), or other attributes that allow buyers to assess the value of the access without the company being named explicitly.

This is one area where organisational context and AI-assisted matching may be useful: an advertisement that describes a company of a particular size, in a particular industry, using specific software, in a specific location, may match an organisation’s profile even without a direct name match. Any such match requires careful human validation before conclusions are drawn.

Ransomware leak sites

Many ransomware groups operate leak sites where they publish the names of alleged victims and, where ransom demands are not met, stolen data. An appearance on a ransomware leak site may indicate: active extortion, confirmed data theft, a supplier compromise affecting the organisation, a historic incident that was not previously disclosed, a false claim used to attract ransom payment, or an attack on a similarly named organisation.

Ransomware attacks often involve data theft that occurs days or weeks before any encryption or disruption becomes visible. A company may see its data published before it experiences any obvious operational impact. This makes external monitoring of leak sites particularly valuable for early warning.

False positives, old data and recycled credentials

Not every dark-web alert represents a current threat. Old credentials may remain in criminal datasets for years after the original breach. The same dataset may be sold or shared repeatedly. Data may be combined from multiple breaches. Fake data may be included to attract buyers. A former employee may appear alongside current staff. Old company domains may still be associated with the business. A password may already have been changed. An alert may relate to a similarly named organisation.

However, old data can still present a genuine risk:

• Old passwords may reveal naming conventions still in use
• Former systems or domains may provide useful context for phishing
• Personal information about executives or employees remains valuable to criminals
• Old credentials may reveal password reuse on systems that have not been updated
• Supplier relationships evident in old data may suggest attack paths
• Security questions or answers may not have been changed
• Historic email addresses may still receive business communications

Does dark-web monitoring prevent attacks?

No. Dark-web monitoring may provide earlier warning that exposure has occurred, but it does not prevent an attack from happening and it does not replace:

• Multi-factor authentication on all critical accounts
• Secure configuration of systems and services
• Regular patching of operating systems and applications
• Endpoint detection and response
• Tested backups stored separately from live systems
• Email security including anti-phishing controls
• Vulnerability management
• Password management using a reputable password manager
• Access reviews and principle of least privilege
• User awareness training
• A tested incident-response process
• Supplier security assurance
• Cyber Essentials certification as a baseline

A business that receives dark-web alerts but lacks basic security controls may repeatedly discover exposure without being able to reduce the underlying risk. Monitoring without remediation is not a security improvement.

Is this relevant to SMEs?

The Google enterprise service is designed primarily for organisations with security operations teams: larger businesses, SOC teams, threat-intelligence teams, managed security providers and organisations with mature security operations. It is unlikely to be a direct procurement option for most UK SMEs in its current form.

However, the underlying question — whether anyone is monitoring for exposure of business credentials and data — is relevant to every business. Smaller businesses can still have stolen credentials in criminal markets, exposed remote access being advertised, compromised supplier accounts, ransomware group claims, leaked employee information, reused passwords being exploited and criminal impersonation of the business.

SMEs may obtain some level of monitoring through: managed IT providers that include threat monitoring in their services, managed security providers, cyber-insurance policies that include breach-alert services, identity-protection platforms, general breach-monitoring services, or specialist threat-intelligence providers.

Privacy and data-protection considerations

Dark-web monitoring may involve the processing of employee email addresses, personal names, telephone numbers, job titles, identity data, leaked passwords, customer records and other personal information from breach evidence or criminal-source data. Businesses should ensure they have considered:

• Lawful basis for processing personal data in a monitoring context
• Purpose limitation — monitoring data should not be used for unrelated purposes
• Data minimisation — monitoring only what is necessary
• Access restrictions on alert data and breach evidence
• Retention periods for monitoring records
• Supplier processing agreements with any monitoring provider
• International transfers if monitoring data is processed outside the UK
• Employee transparency — staff should understand that monitoring may identify their credentials
• Incident records that may be required for a data-breach assessment
• Whether the alert itself constitutes a new personal-data breach requiring ICO assessment

Not every dark-web alert automatically constitutes a new reportable personal-data breach. The organisation must establish: whether the data is genuine, whether it relates to the organisation’s processing, when the original breach occurred, what risk the exposure creates for individuals, and whether reporting thresholds under UK GDPR are met. Organisations should obtain appropriate legal or data-protection advice where exposed personal data may trigger notification obligations.

Immediate actions

1. 1Identify the owner: nominate a named person responsible for receiving and investigating dark-web alerts
2. 2List what should be monitored: domains, brands, subsidiaries, key executives, critical suppliers, critical systems, remote-access services
3. 3Confirm the response process: decide what happens when a password is found, data is leaked, network access is advertised, a ransomware claim appears or a supplier is mentioned
4. 4Enable MFA: prioritise email, administrator accounts, VPN, cloud services, finance systems and all remote access
5. 5Review password practices: ensure unique passwords and an approved password manager are used across the business
6. 6Check session revocation: know how to invalidate tokens and active sessions in your identity provider
7. 7Review sign-in logs: ensure appropriate audit data is available and being reviewed
8. 8Test backups: confirm important systems can be restored from a recent backup
9. 9Record insurance requirements: know when and how your cyber insurer must be contacted
10. 10Prepare communications: establish who is authorised to notify staff, customers, suppliers, regulators, insurers and law enforcement
11. 11Test the process: run a tabletop exercise using a simulated leaked-credential alert to confirm the response works in practice
12. 12Review suppliers: confirm whether monitoring and incident support are included in current managed-service contracts

Warning signs

Escalate immediately and involve specialist support if an alert suggests:

• Working credentials are being offered for sale
• Administrator access to your systems is available
• VPN or remote-desktop access is being advertised
• Session cookies or authentication tokens are exposed
• Source code has leaked
• Confidential customer or employee data is published
• Backups or storage systems have been accessed
• A ransomware group has named your organisation
• An initial-access broker advertisement describes your organisation
• Multiple staff accounts appear together in a single dataset
• An executive or administrator account is compromised
• MFA methods have changed without authorisation
• Suspicious mailbox rules or forwarding have been created
• Unknown OAuth applications have been authorised
• A supplier breach has exposed your information
• The data in an alert appears current
• Sign-in logs show suspicious activity on the same account
• Information-stealing malware may be present on a device
• A dormant but still-enabled account appears to have been accessed
• Nobody knows who is responsible for the response

Practical business implications

AI may reduce alert noise

Context-aware analysis may help distinguish relevant threats from keyword matches that happen to include a company name. Security teams that receive fewer but more relevant alerts can investigate each one properly.

AI may also create false associations

Inferred relationships between dark-web content and an organisation require human validation. An AI system that connects a criminal post to a specific business based on partial matching may be wrong, and acting on that error can cause unnecessary disruption.

Earlier warning can reduce impact

A leaked credential identified before use may be contained quickly. An initial-access advertisement spotted before exploitation can allow defences to be reinforced. Early warning from monitoring has genuine operational value when it results in action.

Monitoring creates an operational responsibility

Alerts must be owned, investigated and closed. An organisation that receives monitoring alerts but has no assigned owner, no response process and no follow-through is receiving information without acting on it. Monitoring without response is not security improvement.

Supplier exposure matters

A criminal discussion may concern a trusted third party rather than the business directly. A supplier breach, a compromised cloud provider or a managed-service provider incident may expose business data without any direct attack on the organisation itself.

Credentials are only part of the picture

Stolen browser cookies, authentication tokens, session data, source code and remote-access credentials can represent a more serious and more immediate threat than an old password found in a recycled breach dataset.

Basic controls still matter most

Dark-web monitoring cannot compensate for absent MFA, weak patching, untested backups, shared passwords or unclear incident ownership. Monitoring is more valuable in a business that already has those foundations in place.

The IT Club View

The headline may suggest that Google has launched an AI that roams the dark web catching hackers. The reality is less dramatic and potentially more useful.

Security companies already collect enormous volumes of dark-web data. That has been true for years. The difficult part is filtering that information into findings that are relevant, credible, urgent and actionable for a specific organisation.

Traditional keyword monitoring can produce too much noise. Gemini may improve the process by understanding more about the organisation and why a particular criminal post might matter to it specifically. That is a meaningful potential improvement, if it works as described.

But AI does not remove the need for human judgement, evidence validation, clear incident ownership, strong security controls or a tested response process. A business that receives an accurate, relevant alert and then does nothing useful with it has not improved its security.

IT Club recommends that every business, regardless of the monitoring platform it uses or does not use, should be able to answer these questions: Who receives exposure alerts? Who investigates them? How quickly can credentials be disabled and sessions revoked? Are affected devices checked as part of the response? Are insurers and legal advisers available when needed? Is the outcome documented?

Related business questions

What is dark-web monitoring?

Dark-web monitoring is the practice of searching criminal sources — underground forums, credential markets, ransomware leak sites and other sources not indexed by standard search engines — for information related to a specific organisation. The aim is to identify exposure of credentials, data or access before criminals exploit it.

What has Google launched?

Google has introduced a dark-web intelligence capability within Google Threat Intelligence that uses Gemini to build an organisational profile and identify dark-web findings that may be relevant to a specific organisation. According to Google, it is designed for security teams and is currently available in public preview. Access requires Google Threat Intelligence licensing.

Is Google’s dark-web monitoring tool free?

No. The dark-web intelligence capability is part of Google Threat Intelligence, an enterprise security platform. It is not a free consumer feature. Access and pricing details should be confirmed with Google Cloud or a Google account representative, as enterprise licensing is typically subscription-based and not publicly listed at a fixed price.

Is this available to ordinary Gmail users?

No. This is an enterprise threat-intelligence service requiring Google Threat Intelligence access. It is not automatically available to Gmail, Google One or standard Google Workspace users. Ordinary Gmail users no longer have access to the consumer Dark Web Report, which was discontinued in early 2026.

Is this the old Google Dark Web Report?

No. The Google Dark Web Report was a consumer service for Google One subscribers that monitored personal information associated with a Google account. It was discontinued in early 2026. The new service is an enterprise threat-intelligence capability with different licensing, different data sources, different scope and a different intended audience. The similar terminology may cause confusion, but the services are unrelated in purpose.

What is Google Threat Intelligence?

Google Threat Intelligence is an enterprise security platform that consolidates threat data from Google’s own research, Mandiant intelligence operations and VirusTotal. It provides security teams with threat information to help them understand, prioritise and respond to cyber threats. The new dark-web intelligence capability is one component within this wider platform.

How does Gemini monitor dark-web threats?

According to Google, Gemini builds a profile of the organisation using business context and then analyses dark-web information against that profile. Rather than matching simple keywords, it attempts to understand relationships between criminal activity and the specific organisation, prioritise relevant findings and explain why a particular item may matter. A human analyst remains responsible for validating and acting on any finding.

What is an organisational threat profile?

An organisational threat profile is a description of a business’s characteristics used to contextualise threat intelligence. It may include company names, domains, brands, subsidiaries, executives, suppliers and technologies. In Google’s system, Gemini is said to build and maintain this profile automatically, allowing it to recognise threats that may relate to the organisation even without an exact name match.

What information is available on the dark web?

Criminal sources may include stolen credentials, leaked databases, initial-access advertisements, ransomware claims, stolen documents, source code, API keys, session cookies, financial records, identity information, phishing kits and discussions about planned attacks. The type and quality of information varies widely between sources, and not everything claimed is authentic.

Can dark-web monitoring find stolen passwords?

Yes, this is one of the most common findings. Credential data — email addresses combined with passwords — appears widely in criminal markets following data breaches. Whether a specific stolen password is current, has been changed, or is being actively used requires investigation after the alert.

Can it find active network access for sale?

Initial-access broker advertisements are monitored by threat-intelligence platforms. These advertisements may describe a company without naming it directly, using attributes such as industry, country, size and available access type. AI-assisted matching may help identify when such an advertisement relates to a specific organisation, though human validation is essential.

What is an initial-access broker?

An initial-access broker is a criminal who obtains access to an organisation’s network or systems and sells that access to other criminals, typically ransomware groups. The access may be via VPN credentials, remote desktop, administrator accounts or other entry points. Advertisements are sold on underground forums and often describe the target in general terms to avoid identifying the victim directly.

What is a ransomware leak site?

A ransomware leak site is a website operated by a ransomware group where it publishes the names of alleged victims and, when ransom demands are not met, samples or full copies of stolen data. These sites are monitored by threat-intelligence providers and can provide early warning that an organisation has been attacked, sometimes before the organisation itself is aware.

Can dark-web monitoring prevent ransomware?

No. Monitoring may provide earlier warning that credentials have been stolen or that access is being advertised, allowing the business to act before an attack occurs. But it does not prevent ransomware by itself. Prevention requires MFA, patching, secure configuration, endpoint protection, email security, user awareness and tested backups.

Does dark-web monitoring cover the whole dark web?

No monitoring service has complete coverage. Criminal infrastructure is distributed across Tor hidden services, invitation-only forums, encrypted messaging channels, private groups, paste sites and many other sources. Coverage varies between providers. New sites are created continuously. Some criminal communications are never visible to monitoring services.

Can criminals post fake breach claims?

Yes. Fake data is used to attract buyers, inflate the apparent value of a criminal’s offering, gain reputation, or generate concern. Organisations may also appear on ransomware leak sites based on false claims or mistaken identity. Every alert should be validated, and no claim should be treated as confirmed without investigation.

What should I do if an employee password is leaked?

Validate the account, reset the password to a unique one not used elsewhere, revoke active sessions and refresh tokens, confirm MFA is in place and has not been tampered with, review sign-in activity for the account, check whether the password was reused on other systems, and investigate the device used by the account holder. Document every step.

Is changing the password enough?

Not always. If an attacker holds an active session token or authentication cookie, they may continue to have access even after the password is changed, because the token was issued before the password reset. Session revocation is necessary in addition to the password change. If the device was infected by an information stealer, the new password may also be captured immediately.

Should I revoke active sessions?

Yes, where the platform supports it. Revoking sessions invalidates existing authentication tokens and forces all signed-in devices to re-authenticate. In Microsoft 365 and Entra ID, this can be done through the admin centre or PowerShell. In Google Workspace, administrators can sign out specific users through the admin console. Check current official documentation for the correct current procedure.

What are stolen browser cookies?

Browser cookies include session tokens that authenticate a user to a web application. If these cookies are stolen by malware, a criminal can use them to access the application without needing a password or MFA code, because the session was already authenticated. This is sometimes called a pass-the-cookie attack. Password resets do not automatically invalidate stolen session cookies.

What is an information stealer?

An information stealer (also called infostealer) is a type of malware that captures credentials, browser cookies, session tokens, saved passwords, autofill data, browser history and other sensitive information from an infected device. The data is sent to criminals and may be sold in stealer-log markets. A device infected by an infostealer may expose every account the user accessed while the malware was active.

Does an old leaked password still matter?

Yes, for several reasons. It may reveal a password pattern still in use elsewhere. It may confirm personal information useful for phishing. It may still be in use if the person has not changed it. It may have been reused on other accounts. Old exposure can lower the response priority but should not be treated as irrelevant without investigation.

Should former employees be monitored?

Yes, in the sense that the domains and brands associated with the organisation remain relevant regardless of who originally used a credential. Old employee accounts that were not properly offboarded may still provide access. Exposed credentials from former employees can reveal systems, naming conventions and access paths still relevant to the business.

Can supplier breaches expose my business?

Yes. A compromised supplier, managed service provider, cloud platform or software vendor may expose data that belongs to your business, provide attackers with access that extends to your systems, or reveal credentials shared between your organisation and the supplier. Supply-chain attacks and third-party breaches are a significant source of business exposure.

Does dark-web monitoring replace MFA?

No. MFA prevents a stolen password from being used to log in. Dark-web monitoring may detect that a password has been stolen. Both are useful but serve different purposes. MFA is a preventive control; dark-web monitoring is a detective control. Neither replaces the other.

Does it replace Cyber Essentials?

No. Cyber Essentials covers preventive technical controls including firewalls, secure configuration, access control, malware protection and software updates. Dark-web monitoring is a detective capability that helps identify exposure after it has occurred. Both have a role; neither substitutes for the other.

Does it replace antivirus or EDR?

No. Antivirus and endpoint detection and response (EDR) protect devices from malware in real time. Dark-web monitoring looks for evidence of past exposure in criminal sources. EDR may detect the information-stealing malware that caused the credential exposure that the dark-web alert subsequently identified.

Does it replace a security analyst?

No. AI-assisted monitoring can help prioritise and contextualise findings, but every alert still requires human validation before action. A security analyst, IT administrator or managed security provider must assess whether the finding is credible, decide the appropriate response, execute the remediation and document the outcome.

Is dark-web monitoring suitable for small businesses?

The Google enterprise service is aimed at organisations with security operations teams. However, the underlying need — knowing whether your business credentials or data have appeared in criminal markets — is relevant to every business. Smaller businesses can access monitoring through managed IT providers, managed security services, cyber-insurance benefits, breach-monitoring platforms or identity-protection services.

Who should receive dark-web alerts?

A named individual or team should be responsible for receiving, reviewing and acting on dark-web alerts. That person needs the authority to reset credentials, revoke sessions, escalate to management and contact advisers. Alerts should not be sent to a shared inbox with no assigned owner or to someone who does not have the access to act on them.

When should the ICO be informed?

The ICO should be notified within 72 hours of becoming aware of a personal-data breach that poses a risk to individuals’ rights and freedoms. A dark-web alert does not automatically constitute a new reportable breach. The organisation must assess whether the exposed data is genuine, relates to its processing, is likely to result in harm and meets the reporting threshold. Appropriate data-protection advice should be obtained.

When should a cyber insurer be contacted?

Review your cyber-insurance policy immediately after any significant dark-web alert. Policies typically specify when the insurer must be notified, which may be promptly after discovering a possible incident rather than only after confirming one. Delayed notification can affect cover. Keep the insurer’s emergency contact details readily available.

How should false positives be handled?

A false positive should be documented, including the reason it was determined to be irrelevant, and the alert should be closed with that explanation recorded. The false-positive rate should be tracked over time to identify whether the monitoring profile needs adjusting. A high rate of false positives may indicate that keywords or profile attributes are too broad.

What records should be kept after an alert?

Record the date and time of the alert, the monitoring source, the affected account or asset, the type of information exposed, the validation steps taken, the actions performed, the person responsible, the outcome, whether a data-breach assessment was conducted and the next review date. This record may be required for insurance, regulatory or legal purposes.

How often should dark-web monitoring be reviewed?

At minimum, the monitoring profile, alert ownership, response process and insurer contacts should be reviewed at least annually and whenever the business changes significantly: new domains, acquisitions, executive changes, key staff departures, supplier changes or major system changes. Open alerts should be reviewed regularly until closed.

Operational Heartbeat

External exposure changes continuously. The monitoring profile becomes stale as employees join and leave, passwords are reused across services, domains are acquired or disposed of, brands evolve, suppliers change, cloud services are introduced, credential theft occurs, malware infections happen, criminal datasets are republished, ransomware groups reorganise, remote-access infrastructure changes, subsidiaries are acquired, alert owners leave the business and incident contacts change.

A recurring review should examine: monitored domains and brands, key executives included in the profile, critical suppliers, active remote-access systems, alert routing and destinations, response ownership, licensing and access status, integration health, false-positive rate, open alerts, response time data, unresolved credential findings, pending session-revocation actions, outstanding device investigations, insurer and legal contact details, incident playbooks and their currency, dates of last tabletop exercises, named overall owner, corrective actions from the previous review and next review date.