Asset review

Your internet-facing services and assets are your most exposed surface. For every asset that is reachable from the internet, you should know what it is, why it is exposed, who decided to expose it and which team is responsible for it. An exposed asset without this information is a serious risk, so this is a process to run with discipline. Vulmon Recon does not only discover and scan, as an ordinary EASM tool does; it leads you through this practice. Every in-scope domain, IP address and port gets a business justification (the Asset purpose field) and a responsible person or team (owners), or it is closed.

Why it matters

Vulmon Recon does not stop at finding your attack surface. Asset review is the step that makes it smaller. Fixing a known issue removes one weakness, but the service stays exposed, together with every vulnerability nobody has found yet. Closing a service nobody can justify removes the exposure itself. Continuous scanning tells you if it comes back. The method, step by step, is on How to reduce your external attack surface.

The same two fields do most of the day-to-day work. When a critical finding appears on an asset with an owner, the ticket goes straight to that team instead of starting with "whose is this?". The justification tells your team how critical an asset is, so they do not treat the same CVE on a marketing microsite and on a payment API alike. And because every purpose keeps its history, the reason an asset is exposed stays on record after the person who wrote it has left.

What to write

One or two lines are enough. Say what the asset is, why it is exposed to the internet and, if you want, who approved the exposure. If the exposure is temporary, say until when, and review it on that date. Review the line at least once a year, and whenever the owner changes. If nobody can write a line like this, the asset is a candidate to close.

Two examples:

• "Customer portal. Public by design, approved by the CISO in 2025."
• "SFTP for the payroll vendor. Temporary until 2026-03-31; review then."

The standards that ask for the same thing

ISO/IEC 27001 (A.5.9) asks for an inventory of information and associated assets, with owners. PCI DSS asks for a current inventory of in-scope system components (Requirement 12.5.1), and for every allowed service, protocol and port to be identified, approved and tied to a defined business need (Requirement 1.2.5). DORA (Article 8) asks for ICT assets to be identified and documented. CIS Controls v8 asks the asset inventory to record each asset's owner, its department and whether it was approved to connect to the network (Safeguard 1.1). In Türkiye, BDDK asks for an inventory and classification of information assets, and BİGR for inventory management of assets. The compliance evidence and asset inventory reports are built from the purposes and owners you record here.