# How we run the first vulnerability assessment in Tenable One > A two-week, day-by-day walkthrough of the first vulnerability assessment FM CyberSecurity runs on Tenable One for a new Norwegian SMB customer. Source: https://fmcybersecurity.com/en/insights/exposure/first-vulnerability-assessment-in-tenable-one/ Locale: English Other locale: https://fmcybersecurity.com/insights/exposure/forste-sarbarhetsanalyse-i-tenable-one/ ## Metadata - Date: 2026-05-26 - Author: anders-helgesplass - Topic: exposure - Format: guide - Partner: tenable Here is the two-week first-scan engagement FM CyberSecurity runs on [Tenable One](/en/partners/tenable/) for a new Norwegian SMB customer, day by day. The point of the first scan is a defensible baseline, not a long PDF. ![Tenable logo and First Assessment, FM CyberSecurity](../../../assets/news/first-vulnerability-assessment-in-tenable-one-inline.png) ## 1. Scoping call, day 1 We start with a thirty-minute call to agree what gets scanned. The first question is which systems carry contract obligations: the e-mail platform, the file shares, the customer-facing web app, the cloud workloads, the Active Directory. Those are in scope. The lab in the corner running an old print server is out, unless someone can still log into it. You leave the call with a one-page scope: in-scope IP ranges, public domains, cloud accounts, AD forests, and a named contact on your side who can answer questions during the scan. ## 2. Asset discovery, day 2 to 3 Most SMBs we work with cannot list their assets without a discovery sweep. We run a light discovery pass first so the real scan does not miss anything obvious. For internal ranges we pull from your DHCP, your AD, and a low-impact ping sweep. For external, we pull what attackers see: certificate transparency logs, DNS, the public IPs your provider has assigned you. The result is a working asset list with owners. If you cannot name an owner for a system, that system is the first finding before any scanner runs. ## 3. Standing up the Tenable One tenant, day 3 We provision the [Tenable One](/en/partners/tenable/) tenant under FM CyberSecurity's partner account and add your named users with the right roles. Internal scanning runs through one or two Tenable Nessus scanners deployed in your network (virtual appliance or container). External scanning runs from Tenable's cloud. Cloud workloads connect through native connectors for AWS, Azure, or Google Cloud, read-only at this stage. If Active Directory is in scope, we install the Tenable Identity Exposure collector against a read-only service account on a domain controller. Identity Exposure surfaces AD configuration risk; it does not replace your PAM. If you run CyberArk on top, the two complement each other. ## 4. Initial sweep, day 4 to 7 We launch four scans in parallel, sized to your scope: - Internal authenticated vulnerability scan against the in-scope IP ranges, using a least-privilege scanning account. - External unauthenticated scan against your public IPs and domains. - Web application scan against the customer-facing apps you named. - Cloud Security and Identity Exposure run continuously once connected, so the first read lands during the same week. Authenticated scans matter. An unauthenticated scan finds the version banner. An authenticated scan finds the missing Windows patch behind it. The signal-to-noise gap between the two is the gap that decides whether your first report is useful. ## 5. The noise pass, day 8 The raw output is loud. A first scan against a real network will surface thousands of findings, and most of them are not what you should fix first. We run a noise pass before anyone sees the data: - De-duplicate findings across scanners. - Tag known-good internal tools (jump hosts, monitoring agents, the backup appliance) so their expected behaviour does not read as risk. - Suppress findings that are already mitigated by a compensating control we can verify. - Mark anything that needs a vendor exception, with the reason in writing. What is left is the real list. ## 6. Business-context tagging, day 9 A CVSS score does not know which of your servers runs payroll. We tag every asset against the contract-bearing systems from step 1: payroll, customer data, the e-commerce stack, the HR system. Tenable One uses these tags to lift the findings that touch those systems above the rest. The output is a prioritised view: critical findings on contract-bearing systems first, then exploitable findings on supporting systems, then everything else. Boards read the first cut. Operators work the second. ## 7. Findings review meeting, day 10 A ninety-minute working session with your IT lead and one business owner per critical system. We walk through the top findings, agree which are real, which need a vendor exception, and which need to be fixed. Anything where you and we disagree on severity, we mark and revisit. Two outputs come out of this meeting: a remediation list with named owners and target dates, and a short list of compensating controls we will accept while a fix is in progress. ## 8. Handover document, day 11 to 12 You get a written handover. It is short on purpose: - Scope, what was scanned and what was not. - Asset inventory with owners and business tags. - Top findings by business impact, with remediation owners and dates. - Exceptions and compensating controls, with the reason in writing. - The tenant configuration we leave running: scanners, connectors, scan windows, user roles. - The first metrics baseline: total critical and high findings, mean age, percentage of assets with an owner. The handover is what your auditor reads, and what your board asks about next quarter. ## 9. What changes between the first scan and the ongoing programme The first scan is a one-off. The programme that follows is not. We move to weekly internal scans, daily external and cloud reads, and a monthly findings review. The metrics baseline from step 8 becomes the trend line. For how we run that ongoing programme, see [how we run the vulnerability programme in Tenable One](/en/insights/exposure/how-we-run-the-vulnerability-program-in-tenable-one/). For the platform choice itself, see [why we picked Tenable for exposure management](/en/insights/exposure/why-we-picked-tenable-for-exposure-management/) and the [Nessus vs Tenable Vulnerability Management vs Tenable One](/en/insights/exposure/nessus-vs-tenable-vulnerability-management-vs-tenable-one/) comparison. ## Next action Talk to Anders in [FM CyberSecurity's assessments practice](/en/services/assessments/) for a scoped first vulnerability assessment in Tenable One. We come back with a written scope, a tenant configuration, and a defensible baseline you can put in front of an auditor or a board. ## FAQ ### How much access do you need from us to run the first scan? For internal scanning, a least-privilege scanning account on Windows and Linux assets and a route from a Nessus scanner to the in-scope ranges. For external scanning, your public IP ranges and domains, no access required. For cloud, a read-only role in each subscription or project. For Active Directory, a read-only service account on a domain controller. We document every access we use, with an expiry date, and remove it when the engagement ends if you ask. ### How long does the first scan take, end to end? Two weeks from the scoping call to the handover, for a typical Norwegian SMB with one or two sites, one cloud tenant, and one AD forest. Day 1 is the scoping call, days 2 to 3 are discovery and tenant setup, days 4 to 7 are the scans, days 8 to 10 are noise reduction and the review meeting, days 11 to 12 are the handover. Larger or multi-entity scopes add a week. ### What do we get at the end? A live Tenable One tenant configured to your environment, an asset inventory with owners and business tags, a prioritised remediation list with named owners and dates, a written record of exceptions and compensating controls, and a metrics baseline you can show your board and your auditor. ### Can we run this without IT downtime? Yes. Authenticated vulnerability scans on modern Windows and Linux systems are read operations and do not cause outages on healthy infrastructure. We schedule scans in agreed windows, throttle scan rate to avoid loading low-end devices, and pause if your monitoring flags anything. The web app scan against a production site is the one place where we plan around a staging environment or a low-traffic window, by agreement. ### Do you scan our identity systems in the first assessment? If Active Directory is in scope, yes, through Tenable Identity Exposure. It surfaces AD configuration risks: stale admin accounts, weak Kerberos settings, risky delegations, and trust paths. It is a discovery tool for AD risk, not a privileged access management product. If you already run CyberArk, Identity Exposure complements it; if you do not, the findings are a useful input to the PAM conversation. --- --- For the full documentation index, see https://fmcybersecurity.com/llms.txt For the complete corpus as a single document, see https://fmcybersecurity.com/llms-full.txt