{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/reconcile-psa-rmm-identity-billing-inventories/", "item": { "id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "slug": "reconcile-psa-rmm-identity-billing-inventories", "url": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories.md", "json": "https://update.dsesecurity.com/api/v1/posts/reconcile-psa-rmm-identity-billing-inventories/" }, "title": "Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts", "summary": "PSA, RMM, identity, security, backup, and billing systems answer different questions. Reconcile them so unmanaged assets, stale agents, unknown identities, licensing gaps, and contract mismatches become owned work.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/", "type": "Person" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-17T13:22:00+00:00", "modified_at": "2026-08-17T19:22:09+00:00", "reviewed_on": "2026-08-17", "reading_minutes": 3, "word_count": 631, "potentially_affected": "PSA configuration items; RMM agents; identity directories; endpoint security; backup; monitoring; network inventories; cloud subscriptions; contracts; invoices; customer ownership; and service reporting.", "dse_recommendation": "Define authoritative fields, create stable asset and customer keys, compare operational systems on a schedule, route mismatches to owners, confirm lifecycle state with customers, and preserve reconciliation evidence.", "primary_source": { "name": "NIST Cybersecurity Framework 2.0 Implementation Examples", "url": "https://www.nist.gov/document/csf-20-implementations-pdf", "published_on": "2024-02-26", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts: knowing assets and services is a continuing governance outcome

\n

NIST’s Cybersecurity Framework 2.0 Implementation Examples provides example actions for CSF outcomes rather than prescribing one platform. For Asset Management, the examples include maintaining inventories of hardware, software, systems, and services; identifying owners; using discovery and inventory tools; and updating records as the environment changes. The CSF also connects asset knowledge with risk, protection, monitoring, response, and recovery.

\n

CISA’s Cross-Sector Cybersecurity Performance Goals similarly recommend maintaining regularly updated inventories of assets with IP addresses where relevant, hostnames, owners, and other information needed to identify unauthorized or unmanaged systems. CISA’s MSP advisory calls for providers and customers to understand responsibilities, secure remote-management tools, restrict access, and monitor provider activity.

\n

These sources do not declare that PSA, RMM, billing, or identity data is universally authoritative. Each system observes a different part of service delivery. An RMM agent can prove that software recently checked in, but not that the device is contractually covered. An invoice can show that a service is billed, but not that protection is deployed. A directory can contain a legitimate dormant account or a stale one. Reconciliation is the controlled process of resolving those differences.

\n\n

DSE recommendation: operate an inventory reconciliation queue

\n

Do not promise a magical single source of truth. Define which system is authoritative for each field, join the records with stable identifiers, and make every unresolved mismatch visible to an owner.

\n
    \n
  1. Define the questions. Decide what the inventory must prove: customer ownership, physical or cloud location, lifecycle state, support tier, contract inclusion, responsible party, identity owner, security coverage, backup coverage, network reachability, and retirement approval.
    2. \n
  2. Name field authorities. The contract may own service entitlement, finance may own invoice status, the customer may own business disposition, identity may own account state, and technical platforms may own last-seen evidence. Record precedence and the process for disputing incorrect source data.
    3. \n
  3. Create stable keys. Prefer immutable customer, tenant, subscription, device, user, and contract identifiers over names. Preserve serial number, cloud resource ID, directory object ID, agent ID, and source-system record ID. Maintain approved aliases after mergers, replacements, and renames.
    4. \n
  4. Compare the critical sets. Identify devices billed but not managed, agents active without a contract item, protected endpoints missing RMM, users licensed but not employed, backups configured without successful recovery evidence, customer networks absent from documentation, and retired assets still reporting.
    5. \n
  5. Route rather than hide conflicts. Give each mismatch a severity, customer, owner, due date, evidence, and allowed resolution. Do not automatically delete an agent, add billing, or grant a license solely because another system contains a record. Those actions can affect service, cost, or access.
    6. \n
  6. Confirm with the customer. Review unresolved ownership, shadow services, exceptions, newly discovered assets, and retirement candidates with authorized customer contacts. Record the decision and effective date, especially when an asset remains reachable but is removed from managed scope.
    7. \n
  7. Measure coverage and ageing. Report reconciliation date, record counts, match rate, unknown owners, stale check-ins, unprotected assets, contract gaps, aged exceptions, and time to resolution. Preserve snapshots so trends and audit questions can be answered.
    8. \n
\n

Factual boundary: NIST and CISA describe asset-management outcomes; they do not endorse a specific MSP data model or make billing data a security authority. Discovery tools can miss offline assets, duplicate virtual systems, or observe devices outside contractual scope. Customer validation and change control remain necessary.

\n

The best reconciliation program does more than improve reporting. It reveals where responsibility is ambiguous before an incident, renewal, or recovery attempt exposes the gap. Success means the provider and customer can explain which assets and identities are managed, what controls are expected, which record supports that claim, and who owns every exception.

\n\n

Official references

\n", "content_text": "Source facts: knowing assets and services is a continuing governance outcome\nNIST’s Cybersecurity Framework 2.0 Implementation Examples provides example actions for CSF outcomes rather than prescribing one platform. For Asset Management, the examples include maintaining inventories of hardware, software, systems, and services; identifying owners; using discovery and inventory tools; and updating records as the environment changes. The CSF also connects asset knowledge with risk, protection, monitoring, response, and recovery.\nCISA’s Cross-Sector Cybersecurity Performance Goals similarly recommend maintaining regularly updated inventories of assets with IP addresses where relevant, hostnames, owners, and other information needed to identify unauthorized or unmanaged systems. CISA’s MSP advisory calls for providers and customers to understand responsibilities, secure remote-management tools, restrict access, and monitor provider activity.\nThese sources do not declare that PSA, RMM, billing, or identity data is universally authoritative. Each system observes a different part of service delivery. An RMM agent can prove that software recently checked in, but not that the device is contractually covered. An invoice can show that a service is billed, but not that protection is deployed. A directory can contain a legitimate dormant account or a stale one. Reconciliation is the controlled process of resolving those differences.\n\nDSE recommendation: operate an inventory reconciliation queue\nDo not promise a magical single source of truth. Define which system is authoritative for each field, join the records with stable identifiers, and make every unresolved mismatch visible to an owner.\n\nDefine the questions. Decide what the inventory must prove: customer ownership, physical or cloud location, lifecycle state, support tier, contract inclusion, responsible party, identity owner, security coverage, backup coverage, network reachability, and retirement approval.\nName field authorities. The contract may own service entitlement, finance may own invoice status, the customer may own business disposition, identity may own account state, and technical platforms may own last-seen evidence. Record precedence and the process for disputing incorrect source data.\nCreate stable keys. Prefer immutable customer, tenant, subscription, device, user, and contract identifiers over names. Preserve serial number, cloud resource ID, directory object ID, agent ID, and source-system record ID. Maintain approved aliases after mergers, replacements, and renames.\nCompare the critical sets. Identify devices billed but not managed, agents active without a contract item, protected endpoints missing RMM, users licensed but not employed, backups configured without successful recovery evidence, customer networks absent from documentation, and retired assets still reporting.\nRoute rather than hide conflicts. Give each mismatch a severity, customer, owner, due date, evidence, and allowed resolution. Do not automatically delete an agent, add billing, or grant a license solely because another system contains a record. Those actions can affect service, cost, or access.\nConfirm with the customer. Review unresolved ownership, shadow services, exceptions, newly discovered assets, and retirement candidates with authorized customer contacts. Record the decision and effective date, especially when an asset remains reachable but is removed from managed scope.\nMeasure coverage and ageing. Report reconciliation date, record counts, match rate, unknown owners, stale check-ins, unprotected assets, contract gaps, aged exceptions, and time to resolution. Preserve snapshots so trends and audit questions can be answered.\n\nFactual boundary: NIST and CISA describe asset-management outcomes; they do not endorse a specific MSP data model or make billing data a security authority. Discovery tools can miss offline assets, duplicate virtual systems, or observe devices outside contractual scope. Customer validation and change control remain necessary.\nThe best reconciliation program does more than improve reporting. It reveals where responsibility is ambiguous before an incident, renewal, or recovery attempt exposes the gap. Success means the provider and customer can explain which assets and identities are managed, what controls are expected, which record supports that claim, and who owns every exception.\n\nOfficial references\n\nNIST, Cybersecurity Framework 2.0 Implementation Examples.\nCISA, Cross-Sector Cybersecurity Performance Goals.\nCISA, Protecting Against Cyber Threats to Managed Service Providers and their Customers.", "content_markdown": "## Source facts: knowing assets and services is a continuing governance outcome\n\nNIST’s [Cybersecurity Framework 2.0 Implementation Examples](https://www.nist.gov/document/csf-20-implementations-pdf) provides example actions for CSF outcomes rather than prescribing one platform. For Asset Management, the examples include maintaining inventories of hardware, software, systems, and services; identifying owners; using discovery and inventory tools; and updating records as the environment changes. The CSF also connects asset knowledge with risk, protection, monitoring, response, and recovery.\n\nCISA’s Cross-Sector Cybersecurity Performance Goals similarly recommend maintaining regularly updated inventories of assets with IP addresses where relevant, hostnames, owners, and other information needed to identify unauthorized or unmanaged systems. CISA’s MSP advisory calls for providers and customers to understand responsibilities, secure remote-management tools, restrict access, and monitor provider activity.\n\nThese sources do not declare that PSA, RMM, billing, or identity data is universally authoritative. Each system observes a different part of service delivery. An RMM agent can prove that software recently checked in, but not that the device is contractually covered. An invoice can show that a service is billed, but not that protection is deployed. A directory can contain a legitimate dormant account or a stale one. Reconciliation is the controlled process of resolving those differences.\n\n## DSE recommendation: operate an inventory reconciliation queue\n\nDo not promise a magical single source of truth. Define which system is authoritative for each field, join the records with stable identifiers, and make every unresolved mismatch visible to an owner.\n\n- Define the questions. Decide what the inventory must prove: customer ownership, physical or cloud location, lifecycle state, support tier, contract inclusion, responsible party, identity owner, security coverage, backup coverage, network reachability, and retirement approval.\n\n- Name field authorities. The contract may own service entitlement, finance may own invoice status, the customer may own business disposition, identity may own account state, and technical platforms may own last-seen evidence. Record precedence and the process for disputing incorrect source data.\n\n- Create stable keys. Prefer immutable customer, tenant, subscription, device, user, and contract identifiers over names. Preserve serial number, cloud resource ID, directory object ID, agent ID, and source-system record ID. Maintain approved aliases after mergers, replacements, and renames.\n\n- Compare the critical sets. Identify devices billed but not managed, agents active without a contract item, protected endpoints missing RMM, users licensed but not employed, backups configured without successful recovery evidence, customer networks absent from documentation, and retired assets still reporting.\n\n- Route rather than hide conflicts. Give each mismatch a severity, customer, owner, due date, evidence, and allowed resolution. Do not automatically delete an agent, add billing, or grant a license solely because another system contains a record. Those actions can affect service, cost, or access.\n\n- Confirm with the customer. Review unresolved ownership, shadow services, exceptions, newly discovered assets, and retirement candidates with authorized customer contacts. Record the decision and effective date, especially when an asset remains reachable but is removed from managed scope.\n\n- Measure coverage and ageing. Report reconciliation date, record counts, match rate, unknown owners, stale check-ins, unprotected assets, contract gaps, aged exceptions, and time to resolution. Preserve snapshots so trends and audit questions can be answered.\n\nFactual boundary: NIST and CISA describe asset-management outcomes; they do not endorse a specific MSP data model or make billing data a security authority. Discovery tools can miss offline assets, duplicate virtual systems, or observe devices outside contractual scope. Customer validation and change control remain necessary.\n\nThe best reconciliation program does more than improve reporting. It reveals where responsibility is ambiguous before an incident, renewal, or recovery attempt exposes the gap. Success means the provider and customer can explain which assets and identities are managed, what controls are expected, which record supports that claim, and who owns every exception.\n\n## Official references\n\n- NIST, [Cybersecurity Framework 2.0 Implementation Examples](https://www.nist.gov/document/csf-20-implementations-pdf).\n\n- CISA, [Cross-Sector Cybersecurity Performance Goals](https://www.cisa.gov/cybersecurity-performance-goals).\n\n- CISA, [Protecting Against Cyber Threats to Managed Service Providers and their Customers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a)." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "url": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-17" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts", "item": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/#article", "identifier": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "url": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/", "headline": "Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts", "description": "PSA, RMM, identity, security, backup, and billing systems answer different questions. Reconcile them so unmanaged assets, stale agents, unknown…", "abstract": "PSA, RMM, identity, security, backup, and billing systems answer different questions. Reconcile them so unmanaged assets, stale agents, unknown identities, licensing gaps, and contract mismatches become owned work.", "articleBody": "Source facts: knowing assets and services is a continuing governance outcome\nNIST’s Cybersecurity Framework 2.0 Implementation Examples provides example actions for CSF outcomes rather than prescribing one platform. For Asset Management, the examples include maintaining inventories of hardware, software, systems, and services; identifying owners; using discovery and inventory tools; and updating records as the environment changes. The CSF also connects asset knowledge with risk, protection, monitoring, response, and recovery.\nCISA’s Cross-Sector Cybersecurity Performance Goals similarly recommend maintaining regularly updated inventories of assets with IP addresses where relevant, hostnames, owners, and other information needed to identify unauthorized or unmanaged systems. CISA’s MSP advisory calls for providers and customers to understand responsibilities, secure remote-management tools, restrict access, and monitor provider activity.\nThese sources do not declare that PSA, RMM, billing, or identity data is universally authoritative. Each system observes a different part of service delivery. An RMM agent can prove that software recently checked in, but not that the device is contractually covered. An invoice can show that a service is billed, but not that protection is deployed. A directory can contain a legitimate dormant account or a stale one. Reconciliation is the controlled process of resolving those differences.\n\nDSE recommendation: operate an inventory reconciliation queue\nDo not promise a magical single source of truth. Define which system is authoritative for each field, join the records with stable identifiers, and make every unresolved mismatch visible to an owner.\n\nDefine the questions. Decide what the inventory must prove: customer ownership, physical or cloud location, lifecycle state, support tier, contract inclusion, responsible party, identity owner, security coverage, backup coverage, network reachability, and retirement approval.\nName field authorities. The contract may own service entitlement, finance may own invoice status, the customer may own business disposition, identity may own account state, and technical platforms may own last-seen evidence. Record precedence and the process for disputing incorrect source data.\nCreate stable keys. Prefer immutable customer, tenant, subscription, device, user, and contract identifiers over names. Preserve serial number, cloud resource ID, directory object ID, agent ID, and source-system record ID. Maintain approved aliases after mergers, replacements, and renames.\nCompare the critical sets. Identify devices billed but not managed, agents active without a contract item, protected endpoints missing RMM, users licensed but not employed, backups configured without successful recovery evidence, customer networks absent from documentation, and retired assets still reporting.\nRoute rather than hide conflicts. Give each mismatch a severity, customer, owner, due date, evidence, and allowed resolution. Do not automatically delete an agent, add billing, or grant a license solely because another system contains a record. Those actions can affect service, cost, or access.\nConfirm with the customer. Review unresolved ownership, shadow services, exceptions, newly discovered assets, and retirement candidates with authorized customer contacts. Record the decision and effective date, especially when an asset remains reachable but is removed from managed scope.\nMeasure coverage and ageing. Report reconciliation date, record counts, match rate, unknown owners, stale check-ins, unprotected assets, contract gaps, aged exceptions, and time to resolution. Preserve snapshots so trends and audit questions can be answered.\n\nFactual boundary: NIST and CISA describe asset-management outcomes; they do not endorse a specific MSP data model or make billing data a security authority. Discovery tools can miss offline assets, duplicate virtual systems, or observe devices outside contractual scope. Customer validation and change control remain necessary.\nThe best reconciliation program does more than improve reporting. It reveals where responsibility is ambiguous before an incident, renewal, or recovery attempt exposes the gap. Success means the provider and customer can explain which assets and identities are managed, what controls are expected, which record supports that claim, and who owns every exception.\n\nOfficial references\n\nNIST, Cybersecurity Framework 2.0 Implementation Examples.\nCISA, Cross-Sector Cybersecurity Performance Goals.\nCISA, Protecting Against Cyber Threats to Managed Service Providers and their Customers.", "datePublished": "2026-08-17T13:22:00+00:00", "dateModified": "2026-08-17T19:22:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Person", "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts" }, "articleSection": [ "Business Continuity", "Cybersecurity", "IT" ], "keywords": [ "Business Continuity", "Cybersecurity", "IT", "Playbook", "Advisory priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 631, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "NIST Cybersecurity Framework 2.0 Implementation Examples", "url": "https://www.nist.gov/document/csf-20-implementations-pdf", "datePublished": "2024-02-26" } } ] } }