[0038] Audit 170 may allow an audit of service instances lifecycle. Audit 170 may also reuse existing platform capabilities enriched with information from Service repository and/or Service registry. [0039] Figure 2 illustrates an exemplary control plane, according to an embodiment of the present invention. Figure 2 details service registration and filtering. As shown in Figure 2, Service Provider (SP) may include a service provisioning API at 210. Platform Component (PC) may include a service provisioning API client as shown by 212. Service Framework Registry (SRF) may include a service information and policy metadata REST API as shown by 214. At 220, service synchronization may support filter and service promotion. At 222, PC may evaluate policy metadata and update platform marketplace 216, as shown by 222. [0040] As shown in Figure 2, SP API, protected using OIDC, may be registered with the Service Framework Registry (SFR). SFR broker information may be synchronized with the PC periodically, either synchronously or asynchronously. Once the synchronization is complete and the policy metadata allows the service to be consumed from the specific platform, the PC may expose the service, by interacting with a platform specific marketplace component, allowing users to consume services on the platform. Services may be made available on platforms based on the policy metadata in the SFR. This may be used to filter services based on characteristics of the platform ( e.g ., region, environment, etc.) and/or the type of service (e.g, multi-tenant services may not be made available in secure, restrictive environments, etc.). The ability to filter and scope services based on a multitude of characteristics may allow for service promotion across environments and presenting new services or upgrading existing services with zero- deployment effort across platforms.