How to Audit Your Company’s Internet Number Resources

  • Post author:
  • Post last modified:July 14, 2026
  • Reading time:24 mins read
You are currently viewing How to Audit Your Company’s Internet Number Resources

What is an Internet number resource audit?

An Internet number resource audit is a structured review of an organization’s IPv4 addresses, IPv6 addresses, Autonomous System Numbers, registry accounts, routing authorizations, supporting documents, and operational controls.

The purpose is to confirm that every resource:

– Is known to the organization
– Is associated with the correct legal entity
– Appears accurately in registry records
– Has a documented allocation, assignment, transfer, or usage basis
– Is routed only by authorized networks
– Has appropriate RPKI and IRR records
– Is protected by secure administrative access
– Is being used efficiently
– Complies with applicable policies and agreements
– Has a clear operational and commercial purpose

A strong audit connects technical data with legal, governance, security, and financial records. It should answer not only “Which IP addresses does the company use?” but also “Who controls them, why are they being used, who can change them, and what would happen if access were lost?”

 

Why companies should audit Internet number resources

Internet number resources often enter a business gradually.

A company may receive an IPv4 allocation from a Regional Internet Registry, obtain provider-assigned space, acquire a business with existing resources, lease addresses for a cloud deployment, or use multiple ASNs across different subsidiaries.

Over time, records can become fragmented.

Common problems include:

– Resources registered to an old corporate entity
– Former employees remaining as registry contacts
– Unknown or undocumented BGP announcements
– Inaccurate WHOIS or RDAP information
– Missing or outdated Route Origin Authorizations
– Stale Internet Routing Registry objects
– Unused IPv4 space
– Overlapping internal assignments
– Expired Letters of Authorization
– Incomplete transfer documentation
– Unmonitored registry-policy changes
– Resources used by third parties without current agreements

These issues can affect network continuity, cybersecurity, regulatory compliance, transferability, and asset value.

NRS has previously examined how poor IP address management can damage enterprise value. The central lesson is that incomplete inventories and weak controls create costs far beyond the network team. They can contribute to outages, security gaps, wasted resources, delayed transactions, and governance risk.

 

What should be included in the audit?

A complete audit should cover all Internet number resources and the systems that support them.

Audit areaWhat should be reviewed
IPv4 resourcesAllocations, assignments, transfers, leases, utilization, and routing
IPv6 resourcesAllocations, addressing plans, routing, adoption, and security
ASNsOwnership, use, BGP peers, route origins, and access controls
Registry accountsLegal entity, users, contacts, authentication, and membership status
DocumentationAllocation records, agreements, transfers, leases, LOAs, and corporate history
RoutingBGP origins, upstreams, route visibility, route leaks, and unauthorized announcements
RPKIROAs, origin ASNs, maximum prefix lengths, validity, and monitoring
IRRroute, route6, and aut-num objects
DNSReverse-DNS authority, nameservers, and operational contacts
SecurityAccount access, multifactor authentication, logging, and incident response
ReputationAbuse history, blocklists, geolocation, and customer use
GovernanceApplicable RIR policies, agreements, fees, and reporting responsibilities
Business useCritical services, customers, revenue dependency, and continuity plans

 

Step 1: Define the audit scope and ownership

The first step is to identify who is responsible for the audit.

Internet number resources cross several business functions, so the review should not be assigned only to a network engineer.

Relevant participants may include:

– Network operations
– Information security
– Legal counsel
– Compliance
– Finance
– Procurement
– Corporate administration
– Risk management
– Mergers and acquisitions
– Executive leadership

One person should act as the audit owner. That person should coordinate evidence, deadlines, findings, and remediation.

The audit scope should cover:

– Every corporate entity
– All business units
– Current and former company names
– Acquired or merged organizations
– Cloud and hosting environments
– Regional offices
– Data centres
– Managed service providers
– Subsidiaries and joint ventures
– Leased-in and leased-out resources
– Provider-assigned address space

The audit should also define a review date. Routing and registry records change, so findings must be tied to a specific point in time.

 

Step 2: Build a complete resource inventory

Create a central inventory of all IPv4 prefixes, IPv6 prefixes, and ASNs used or controlled by the organization.

Information can be collected from:

– RIR accounts
– RDAP and WHOIS records
– IP address management systems
– Router configurations
– BGP monitoring systems
– Cloud accounts
– Firewall rules
– DNS records
– Transit-provider records
– Colocation providers
– Previous invoices
– Allocation and transfer documents
– Lease agreements
– Merger and acquisition files
– Internal spreadsheets
– Procurement records

For every resource, record:

– Prefix or ASN
– Resource type
– Current RIR
– Registered organization
– Internal owner
– Operational contact
– Allocation or transfer date
– Source of the resource
– Current usage
– Origin ASN
– Upstream providers
– RPKI status
– IRR status
– Reverse-DNS authority
– Lease or contract status
– Business criticality
– Supporting document location

Do not assume that the registry account contains the complete inventory. Provider-assigned, leased, or inherited resources may appear elsewhere.

 

Step 3: Confirm the relevant RIR and registry status

The global Internet number resource system is coordinated through five Regional Internet Registries:

ARIN
RIPE NCC
APNIC
AFRINIC
LACNIC

The Number Resource Organization provides an overview of the RIR system and the regions served by each registry.

For each resource, confirm:

– Which RIR administers it
– The registered organization
– Resource status
– Allocation or assignment type
– Registration date
– Available transfer history
– Administrative contacts
– Technical contacts
– Abuse contacts
– Membership or contractual status
– Outstanding fees or administrative issues

Use the authoritative RIR service rather than relying entirely on commercial lookup tools.

RDAP is the modern standardized protocol for accessing registration information. Its query format is defined in RFC 9082, and its response format is defined in RFC 9083.

Save a dated copy of the official record as audit evidence.

 

Step 4: Verify the legal entity and chain of records

The organization using the resource may not be the same legal entity shown in the registry.

This can happen after:

– A company-name change
– A merger or acquisition
– A restructuring
– Creation of a new subsidiary
– Movement of operations between group companies
– Dissolution of an older entity
– A transfer that was not fully reflected internally
– Use of a former trading name

For every resource, compare the registry record with:

– Certificates of incorporation
– Company-name change records
– Merger documents
– Acquisition agreements
– Transfer approvals
– Registry agreements
– Board resolutions
– Invoices
– Lease contracts
– Letters of Authorization
– Historical correspondence

The goal is to create a clear documentary chain connecting the original registration or allocation with the organization currently claiming or exercising control.

If the chain is incomplete, record the gap rather than assuming long-term use has resolved it.

NRS’s guide to protecting IP assets from governance risk explains why accurate records, complete documentation, policy awareness, and legal structure are important to resource continuity.

 

Step 5: Review registry-account security

A company may have complete documentation but still face risk if its registry account is poorly secured.

Review:

– All active users
– User roles and privileges
– Shared accounts
– Multifactor authentication
– Password and recovery policies
– API credentials
– Authorized email domains
– Recovery telephone numbers
– Third-party access
– Former employees
– Consultants and service providers
– Login and change logs
– Emergency recovery procedures

Recommended controls include:

– Individual named accounts
– Least-privilege access
– Phishing-resistant multifactor authentication
– Dual approval for sensitive changes
– Quarterly access reviews
– Immediate removal of departed staff
– Secure storage of recovery information
– Independent logging of important changes
– A tested account-recovery process

Registry access should be treated like access to other critical business systems.

 

Step 6: Audit BGP route origins

For every public prefix, identify which ASN currently originates it.

Compare the result with:

– The company’s intended network design
– Router configurations
– Transit agreements
– Letters of Authorization
– RPKI ROAs
– IRR route objects
– Cloud or hosting arrangements
– Lease agreements

Investigate:

– Unknown origin ASNs
– Multiple-origin prefixes
– Unexpected more-specific announcements
– Routes visible only in some regions
– Prefixes that should be announced but are not
– Announcements continuing after a service ended
– Resources routed through former providers
– Unapproved third-party use

A multiple-origin prefix is not automatically incorrect. Multihoming, migration, distributed infrastructure, and security services may create legitimate cases. The audit should determine whether each origin is understood and authorized.

 

Step 7: Audit RPKI and ROAs

Resource Public Key Infrastructure helps networks verify whether an ASN is authorized to originate a prefix.

A Route Origin Authorization contains:

– An authorized ASN
– One or more IP prefixes
– An optional maximum prefix length

The current technical standard for ROAs is [IETF RFC 9582]

For every routed prefix, check:

– Whether a ROA exists
– Whether the origin ASN is correct
– Whether the prefix matches the announcement
– Whether `maxLength` is appropriate
– Whether the route is valid, invalid, or not found
– Whether old ASNs remain authorized
– Whether planned migration ASNs are covered
– Whether monitoring is enabled
– Who can create, change, or remove ROAs

An overly broad `maxLength` may authorize more-specific announcements beyond the organization’s actual needs. An overly restrictive value can cause legitimate routes to become RPKI invalid.

ROA changes should follow a controlled process. During a migration, the new authorization should normally be established and validated before the old route is withdrawn or its ROA removed.

 

Step 8: Audit IRR objects

Internet Routing Registries allow operators to publish routing-policy information.

Relevant objects may include:

– `route`
– `route6`
– `aut-num`
– `as-set`
– `mntner`

For each resource, determine:

– Which IRR contains the object
– Whether the prefix is correct
– Whether the origin ASN is correct
– Whether duplicate or conflicting objects exist
– Whether old provider objects remain
– Which maintainer controls the object
– Whether access credentials are secure
– Whether the record matches RPKI and live BGP data

Stale IRR records can cause routing-filter problems. Some networks generate filters from IRR data, so incorrect objects may contribute to legitimate routes being rejected or unauthorized routes being accepted.

The audit should not assume that an existing IRR object is accurate simply because it has existed for many years.

 

Step 9: Review Letters of Authorization

A Letter of Authorization may permit a provider or specified ASN to announce an IPv4 prefix.

Create an inventory of every current LOA and record:

– The covered prefix
– The authorized organization
– The authorized ASN
– The purpose
– The issue date
– The expiry date
– The signatory
– The related contract
– The revocation process
– Whether the authorization remains necessary

Look for:

– Expired LOAs
– Documents issued by former employees
– Incorrect ASNs
– Authorization granted to former providers
– Open-ended permissions
– LOAs inconsistent with current RPKI
– Missing documents for active third-party announcements

An LOA is commercial or operational evidence. It is not a substitute for cryptographic route-origin validation or accurate registry records.

 

Step 10: Review leases and third-party use

The company may lease addresses from another organization or allow third parties to use its resources.

For every arrangement, verify:

– Contracting parties
– Prefixes
– Start and end dates
– Permitted uses
– Origin ASN
– Geographic deployment
– Customer identity
– Abuse-handling responsibilities
– RPKI responsibilities
– IRR responsibilities
– Reverse-DNS control
– Geolocation management
– Renewal conditions
– Termination procedures
– Return or renumbering requirements

The technical deployment should match the commercial agreement.

If an agreement has ended, confirm that:

– BGP announcements have stopped
– LOAs have been revoked
– IRR objects have been updated
– ROAs have been changed where required
– Reverse-DNS access has been removed
– Customer assignments have been closed
– Internal records have been updated

 

Step 11: Measure resource utilization

The audit should determine how much address space is actively used and how efficiently it is allocated.

For IPv4 resources, classify addresses as:

– Assigned and active
– Reserved
– Infrastructure
– Customer allocated
– Quarantined
– Available
– Unknown
– Unreachable
– Under migration
– Held for documented growth

Utilization should be measured carefully. A lack of observed traffic does not always mean an address is unused. Some addresses support standby systems, disaster recovery, allowlists, low-volume infrastructure, or customer commitments.

Review:

– Oversized subnets
– Abandoned projects
– Former customer assignments
– Duplicate reservations
– Fragmentation
– Unused public addresses assigned to internal-only systems
– Inconsistent records between IPAM and live configuration
– Capacity forecasts

NRS’s discussion of IP address management and centralized governance risks provides further context on why accurate administration and resilient controls matter.

 

Step 12: Audit IPv6 separately

IPv6 should not be treated as an appendix to the IPv4 audit.

Review:

– Allocated IPv6 prefixes
– Addressing plans
– Current announcements
– ROAs
– IRR objects
– Reverse DNS
– Firewall policies
– Neighbor Discovery protections
– Cloud security groups
– Monitoring coverage
– Customer assignments
– Unused legacy designs
– Documentation and staff knowledge

A network may have secure IPv4 controls but weak IPv6 visibility. This creates risk because operating systems and cloud platforms may enable IPv6 even when the organization does not actively manage it.

Confirm whether IPv6 is:

– Fully deployed
– Partially deployed
– Used only internally
– Enabled unintentionally
– Planned but not active
– Disabled under a documented policy

 

Step 13: Review reverse DNS and geolocation

For each public prefix, confirm:

– Who controls reverse-DNS delegation
– Which nameservers are authoritative
– Whether required PTR records exist
– Whether old providers retain access
– Whether email-related records are correct
– Whether DNS changes are logged
– Whether geolocation reflects actual deployment
– Whether geofeed information is available and accurate

Incorrect reverse DNS may affect email delivery, troubleshooting, security analysis, and customer applications.

Incorrect geolocation can affect content access, fraud controls, regional services, advertising, analytics, and compliance workflows.

 

Step 14: Review reputation and abuse history

IPv4 resources carry operational history.

Audit:

– Major reputation and blocklist results
– Abuse complaints
– Spam history
– Malware reports
– Scanning activity
– Fraud-related reports
– Customer incident records
– Remediation activity
– Address quarantine procedures
– Abuse contact accuracy
– Response times

A listing does not automatically mean a prefix is unusable. Some records may be outdated, disputed, or related to a previous user.

Each finding should be assessed according to:

– Source
– Date
– Evidence
– Current use
– Business impact
– Remediation options

The organization should also review how new customers are assessed before receiving address space.

 

Step 15: Review RIR policies and agreements

Internet number resources operate within policies and service arrangements that may change over time.

For each relevant RIR, review:

– Membership status
– Applicable agreements
– Current fees
– Transfer policies
– Contact-validation requirements
– Resource-review procedures
– Legacy-resource treatment
– RPKI terms
– Reporting duties
– Policy proposals affecting the company

The audit should distinguish between:

– Formal policy
– Contractual obligations
– Operational procedures
– Guidance
– Proposed changes
– Community discussion

NRS provides members with Internet policy updates, training, and opportunities to participate in number-resource policy discussions. Organizations can review [NRS membership options](https://nrs.help/Membership/) and the [NRS frequently asked questions](https://nrs.help/faq/) for more information.

 

Step 16: Assign a business criticality rating

Not every prefix carries the same operational risk.

Assign a criticality level based on factors such as:

– Number of customers
– Revenue dependency
– Difficulty of renumbering
– Use in security allowlists
– Email reputation
– Partner integrations
– Cloud or hosting dependency
– Regulatory importance
– Availability of replacement capacity
– Expected recovery time

A useful classification might include:

– **Critical:** Loss would cause major customer, revenue, or security impact.
– **High:** Loss would disrupt important services and require difficult remediation.
– **Moderate:** Replacement is possible with planned engineering work.
– **Low:** Resource is temporary, unused, or easily replaced.

Critical resources should receive stronger monitoring, access control, documentation, renewal management, and continuity planning.

 

Step 17: Document findings and remediation

Every finding should include:

– Affected resource
– Description
– Evidence
– Risk category
– Business impact
– Responsible owner
– Required action
– Due date
– Verification method
– Current status

A practical priority model is:

PriorityMeaningExample
CriticalImmediate continuity or security riskAn unknown ASN is originating a company prefix
HighSerious control or compliance weaknessA former employee retains registry access
MediumImportant inconsistency requiring correctionAn outdated IRR object remains active
LowDocumentation or optimization improvementAn internal resource description is missing
ObservationNo current defect, but future attention is neededAvailable capacity is approaching a defined threshold

The audit is complete only when material findings have owners and remediation dates.

 

Internet number resource audit checklist

Inventory

– Have all IPv4, IPv6, and ASN resources been identified?
– Are provider-assigned and leased resources included?
– Are acquired and legacy entities covered?
– Does every resource have an internal owner?

Registry

– Is the correct legal entity shown?
– Are contacts current?
– Is membership status clear?
– Are fees and agreements up to date?
– Have authoritative records been archived?

Documentation

– Are allocation and transfer documents available?
– Is the corporate chain complete?
– Are contracts, leases, and LOAs current?
– Is every third-party use documented?

Routing

– Is each origin ASN understood?
– Are unexpected origins investigated?
– Are obsolete announcements removed?
– Are more-specific prefixes authorized?

RPKI and IRR

– Are ROAs correct?
– Is `maxLength` appropriate?
– Are routes RPKI valid?
– Are IRR objects accurate?
– Are old maintainers removed?

Security

– Is multifactor authentication enabled?
– Are shared accounts eliminated?
– Are former staff removed?
– Are changes logged?
– Has account recovery been tested?

Operations

– Is utilization measured?
– Is reverse DNS accurate?
– Is geolocation reviewed?
– Are reputation findings managed?
– Is IPv6 included?

Governance and continuity

– Are policy changes monitored?
– Has business criticality been assigned?
– Is replacement capacity available?
– Is there an incident-response plan?
– Are audit findings tracked to closure?

 

How often should the audit be performed?

A complete audit should generally be performed at least once a year.

Critical records should be monitored continuously or reviewed more frequently.

Additional audits should follow:

– A merger or acquisition
– A corporate-name change
– A network migration
– A major cloud deployment
– A transfer or lease transaction
– A security incident
– A registry-account access problem
– Departure of key network staff
– A significant RIR policy change
– Discovery of an unauthorized route
– Preparation for financing or sale

The audit should also become part of normal due diligence for any transaction involving Internet infrastructure.

 

Final takeaway

An Internet number resource audit is not simply a list of IP addresses.

It is a review of the company’s network identity, registry position, routing authority, documentation, security controls, operational use, and continuity exposure.

A reliable audit answers five fundamental questions:

1. What resources does the company have?
2. Which legal entity and registry records support them?
3. Who can administer and announce them?
4. Are the records, routing, RPKI, and contracts aligned?
5. Can the business maintain continuity if something changes?

When those questions are answered clearly, Internet number resources become easier to protect, manage, transfer, and use responsibly.

Organizations seeking greater awareness of number-resource policy and governance can explore NRS membership or contact NRS for more information.

Frequent Asked Questions

1. What are number resources?

Number resources are the identifiers that allow networks and services to operate on the Internet. They include public IP addresses and Autonomous System Numbers. Infrastructure operators use these resources for routing, customer access, hosting, security controls, partner integrations, and service delivery.

2. Why do number resources need a continuity plan?

Number resources need a continuity plan because instability can affect customer access, partner connections, firewall allowlists, routing, compliance workflows, and revenue-generating services. Even when servers and applications are still online, customers may experience disruption if the underlying number resources are no longer stable or trusted.

3. What can happen if IP address continuity is not protected?

If IP address continuity is not protected, operators may face service disruption, customer complaints, failed integrations, security blocks, migration pressure, reputation issues, and revenue loss. Customers may also need to update DNS records, firewalls, VPNs, payment systems, or partner allowlists, which can create additional operational burden.

4. Who should be responsible for number resource continuity?

Number resource continuity should involve network, legal, commercial, finance, compliance, and customer operations teams. Network teams may manage routing and technical configuration, but contracts, renewals, customer commitments, and business impact require cross-functional ownership.

5. When should operators review their number resource continuity plans?

Operators should review their number resource continuity plans regularly and before any major renewal, customer migration, network expansion, provider change, or IP leasing agreement update. Reviews should also happen after incidents, ownership changes, registry updates, or changes to critical customer services.

Leave a Reply