The home page card states the position plainly. This article is the long version: why BGV technology choices matter, what vendor lock in actually costs, and why building on enterprise standard infrastructure (rather than a proprietary portal) protects both portability and operational sanity.
What "technology" actually means in background verification
In most vendor pitches, technology is the hero. The proprietary platform. The custom dashboard. The AI powered workflow engine. These features are presented as differentiators, reasons to choose one provider over another. But they obscure a more fundamental question: who controls the infrastructure, and what happens to your data, your workflows, and your reporting if you decide to leave?
BGV technology sits in two broad categories. The first is proprietary platforms: purpose built portals owned and operated by the vendor, where your programme lives inside their walls. The second is enterprise standard infrastructure: widely adopted business platforms (Microsoft 365, Azure, SharePoint, Power BI) that the vendor uses to run your programme on tools your own IT team already understands.
The difference matters most at the moments you do not plan for: when you need to switch vendors, when your IT security team audits the data processing chain, when your compliance team needs to extract two years of verification records in a format their own tools can read, or when a regulator asks where candidate data physically resides.
Four technology decisions that matter
Not every technology choice in BGV is consequential. These four are. Click each card to see the detail and the questions you should ask.
Data portability
Integration model
Infrastructure familiarity
Vendor independence
The lock in spectrum: portability by platform architecture
Not all proprietary platforms are equally restrictive, and not all enterprise infrastructure deployments are equally open. The chart below maps five common BGV platform architectures against a portability score, reflecting how easily a client can extract data, preserve integrations, and transition to a new provider.
The pattern is clear. As architecture moves from proprietary to enterprise standard, the client's ability to control their own programme increases. The fully proprietary model scores lowest because every dimension of the programme (data, integrations, user training, reporting) is captive. The full enterprise stack scores highest because nothing about the infrastructure is unique to the vendor.
Proprietary platform vs enterprise infrastructure
The side by side below compares what each model means in practice across the dimensions that matter most to IT, compliance, and procurement teams.
Proprietary platform
- Data lives in vendor controlled storage with vendor defined schemas
- Custom API requires dedicated integration development
- Reporting through vendor's own dashboards and export tools
- User training is platform specific and non transferable
- Security posture depends on vendor's own infrastructure certifications
- Vendor transition requires data migration project (typically 8 to 16 weeks)
- SSO requires custom SAML or OIDC configuration per vendor
Enterprise infrastructure
- Data lives in SharePoint, Azure, or client tenant with standard schemas
- Integration through Microsoft Graph, Power Automate, and standard connectors
- Reporting through Power BI with live data connections
- User training leverages existing Microsoft 365 competency
- Security inherits Microsoft's enterprise compliance certifications
- Vendor transition is a process handover, not a technology migration
- SSO through Azure AD, already configured for most enterprises
Why Microsoft infrastructure matters
OutsourceVerify builds its operator led programmes on Microsoft infrastructure. This is not a technology preference. It is a deliberate architectural decision driven by five practical realities.
Azure: enterprise grade hosting with inherited compliance
Verification data hosted on Azure inherits Microsoft's compliance certifications: ISO 27001, SOC 2 Type II, GDPR readiness, and region specific data residency controls. Your IT security team does not need to audit a BGV vendor's custom infrastructure. They audit Azure, which they likely already trust and use for other workloads. Data residency is configurable by region, meaning candidate data for Indian operations stays in India, European data stays in Europe, and the controls are visible in the Azure portal your IT team already manages.
SharePoint: structured document management that your team already knows
Verification reports, evidence documents, correspondence logs, and audit trails are stored in SharePoint document libraries with metadata tagging, version control, and access permissions. This is not a novel filing system. It is the same tool your legal, compliance, and HR teams use for every other controlled document. When a compliance officer needs to pull verification records for an audit, they use SharePoint search (which they already know) rather than learning a vendor's proprietary report extraction interface.
Teams: real time communication with audit trail
Operator led verification requires ongoing communication between your team and the verification specialists. On a proprietary platform, this communication happens inside the vendor's portal (where you cannot see it) or through unstructured email threads (where nobody can find it later). On Microsoft Teams, every conversation is searchable, timestamped, and retained according to your own organisation's data retention policies. Escalation channels, status updates, and case discussions are all in one place, governed by your IT policies, not the vendor's.
Power BI: reporting that belongs to you
Dashboard reporting on a proprietary platform is controlled by the vendor. You see what they choose to show, in the layout they choose, with the filters they provide. Power BI reporting is built on live data connections to your verification data. Your compliance team can build their own views, apply their own filters, and create their own alerts. When you change BGV vendors, the Power BI dashboards stay. You reconnect the data source and the reporting continues. The reporting layer is yours, not rented.
Enterprise SSO: one identity, zero friction
Single sign on through Azure Active Directory means your HR and compliance users access the BGV programme with the same credentials they use for email, SharePoint, and every other enterprise application. There is no separate login, no separate password policy, no separate MFA configuration. When an employee leaves your organisation and their Azure AD account is deactivated, their access to verification data is revoked automatically. On a proprietary platform, this requires manual deprovisioning or a custom integration that must be maintained.
Three scenarios where technology choice matters
Technology decisions in BGV rarely matter during normal operations. They matter at inflection points. These three scenarios illustrate when the difference between proprietary and enterprise infrastructure becomes consequential.
Scenario 1: Switching BGV providers after 18 months
Your procurement team decides to change BGV vendors. On a proprietary platform, this triggers a data migration project. The vendor's export tools produce a bulk download in a semi structured format that your new provider cannot directly ingest. Evidence documents come as a ZIP archive with internal reference IDs that mean nothing outside the old platform. Integrations with your HRIS must be rebuilt. Your compliance team loses access to historical reports the moment the contract ends. The transition takes 12 to 16 weeks and costs significant internal IT effort.
On enterprise infrastructure, the transition is a process handover. Verification data already lives in your SharePoint tenant (or in a tenant you can clone). Power BI dashboards reconnect to the new data source. Integrations through Power Automate and Graph API persist because the connectors are standard. Your compliance team never loses access to historical records because those records are in your own environment. The transition takes 3 to 4 weeks and is scoped as a process change, not a technology migration.
Scenario 2: IT security team audits the BGV data chain
Your CISO's team conducts an annual vendor security review. On a proprietary platform, they must request and review the vendor's own security documentation: SOC 2 reports, penetration test summaries, data centre certifications, encryption standards. Each proprietary vendor is a unique assessment. The security team has no prior familiarity with the infrastructure and must evaluate it from first principles.
On enterprise infrastructure, the audit is materially simpler. The hosting environment is Azure, which your security team already knows and likely already assesses for other workloads. Data at rest encryption, network segmentation, identity management, and compliance certifications are all inherited from Microsoft's enterprise stack. The security review focuses on the verification process and access controls rather than the infrastructure itself, because the infrastructure is already trusted.
Scenario 3: Regulator asks for two years of verification records
A financial services regulator requests complete verification records for all employees hired in a specific division over the past 24 months. On a proprietary platform, you submit a data extraction request to the vendor. The vendor's export tools may have volume limits, format constraints, or processing delays. The extracted data arrives in the vendor's schema, which your legal team must then reorganise to match the regulator's template. Turnaround: 2 to 6 weeks depending on vendor responsiveness.
On enterprise infrastructure, your compliance team runs a SharePoint query filtered by division and date range. Evidence documents are already in standard formats (PDF, structured metadata). Power BI can generate the summary statistics the regulator needs. The extraction is self service, immediate, and does not depend on the vendor's cooperation or timeline.
Operator led technology in practice
The comparison cards below show how the same operational requirements are met under a proprietary platform model versus an enterprise infrastructure model. The differences are not theoretical. They are the day to day realities that IT, HR, and compliance teams experience.
Proprietary platform approach
- Case initiation: HR logs into vendor portal, fills a custom form, uploads documents to vendor storage
- Status tracking: Vendor dashboard shows status codes defined by vendor
- Report delivery: PDF download from vendor portal or email attachment
- Audit trail: Locked inside vendor system, extractable only on request
- Escalation: Ticket raised in vendor's support system with vendor defined SLAs
- Reporting: Pre built dashboards with limited customisation
Enterprise infrastructure approach
- Case initiation: HR submits via SharePoint form or Power Automate flow integrated with HRIS
- Status tracking: Teams channel with real time updates, SharePoint list with custom views
- Report delivery: SharePoint document library with automated notification and metadata
- Audit trail: SharePoint version history and activity logs, accessible to your compliance team directly
- Escalation: Teams channel with named operators, response times visible in your own environment
- Reporting: Power BI with live connections, fully customisable by your team
Five questions about technology and portability
These questions are designed to surface lock in risk during vendor evaluation or contract renewal. The answers reveal whether the vendor's technology is working for you or working to retain you.
- If we terminate the contract today, what data do we receive, in what format, and within what timeframe? Is this documented in the MSA?
- Which of our current integrations (HRIS, compliance tools, reporting) are vendor specific and would need to be rebuilt with a new provider?
- Where does our candidate data physically reside? Can we choose the data residency region? Can we verify this independently?
- Can our IT security team audit your infrastructure directly, or must they rely on your self reported certifications?
- What is the total internal effort (hours, cost, timeline) required to migrate away from your platform? Have you supported a client through this transition?
Frequently asked questions
Vendor lock in occurs when a BGV provider's technology creates barriers to switching. These barriers include proprietary data formats that make extraction difficult, custom integrations that must be rebuilt with a new provider, platform specific training that is non transferable, and reporting tools that stop working the moment the contract ends. Lock in is rarely explicit. It accumulates gradually as your programme's operational history becomes embedded in infrastructure you do not control.
Three reasons. First, portability: your verification data, reports, and audit trails live in enterprise standard tools (SharePoint, Azure) that you control and that persist regardless of which BGV vendor you use. Second, familiarity: your IT, HR, and compliance teams already know Microsoft 365, so there is zero platform training overhead. Third, trust: Azure's enterprise compliance certifications (ISO 27001, SOC 2 Type II, regional data residency) are independently verified and already accepted by most enterprise security teams. Building a proprietary platform would mean asking clients to trust our infrastructure instead of Microsoft's.
It can be, in specific circumstances. If your organisation does not use Microsoft 365, if your BGV volume is very high and you need a platform with built in workflow automation that exceeds what Power Automate can provide, or if your programme requires highly specialised features (such as candidate self service portals with integrated ID verification), a proprietary platform may add genuine value. The key is to evaluate the lock in cost alongside the feature benefit. Ask the five portability questions in this article, and ensure the contract includes binding data portability guarantees with specific formats and timelines.
On enterprise infrastructure, data portability is straightforward because the data already lives in your environment (or in an environment using standard formats). SharePoint document libraries can be exported, cloned, or migrated using native Microsoft tools. On a proprietary platform, portability depends entirely on the vendor's willingness and technical capability to export your data in a usable format. Best practice: ensure your MSA includes a data return clause specifying the format (CSV or structured JSON for case data, original format for evidence documents), the timeline (typically 30 days), and the completeness guarantee (all records, not just active cases).
Enterprise SSO (single sign on) means your users access the BGV programme using the same identity and credentials they use for all other enterprise applications, typically through Azure Active Directory. This eliminates separate logins, separate password policies, and separate MFA configurations. More importantly, it means access governance is automatic: when an employee's Azure AD account is deactivated (because they leave the organisation or change roles), their access to verification data is revoked immediately. On a proprietary platform, SSO usually requires a custom SAML or OIDC integration that must be configured, maintained, and tested separately.
A vendor's proprietary dashboard shows what the vendor chooses to show, with the filters and layouts they provide. Power BI connects to your live verification data and lets your team build their own views, apply their own filters, create their own alerts, and share reports through your own Microsoft 365 environment. When you change BGV vendors, the Power BI dashboards and report templates stay in your tenant. You reconnect the data source and the reporting continues. The critical difference is ownership: proprietary dashboards are rented; Power BI reports are yours.
No. The infrastructure layer (where data is stored, how users authenticate, how reports are delivered) is separate from the verification methodology (how checks are conducted, which sources are contacted, how evidence is evaluated). Microsoft infrastructure handles the plumbing. The operator led methodology handles the verification. A programme built on SharePoint and Azure can be just as thorough, just as fast, and just as defensible as one built on a proprietary platform. The difference is that the plumbing does not create lock in.
The principle of enterprise standard infrastructure still applies. The specific tools change (Google Drive instead of SharePoint, Looker Studio instead of Power BI, Google Workspace SSO instead of Azure AD), but the architectural philosophy is the same: build on infrastructure the client already uses and trusts, rather than introducing a proprietary layer. OutsourceVerify's primary stack is Microsoft because the majority of our enterprise clients operate on Microsoft 365, but the data formats and processes are designed to be transferable across platforms.
References & further reading
- How We Operate: the operating methodology section on the home page, where this deep dive series originates.
- Speed vs artificial closure (article 01): why reported TAT numbers obscure more than they reveal.
- Data handling (article 09): the companion piece on data residency, retention, and processing controls.
- Compliance brief: audit trail documentation and the 15 questions TPRM teams actually ask.
- TPRM self assessment: pre scored vendor evaluation framework including the technology and portability questions above.
- Microsoft, "Microsoft 365 for enterprise: compliance and security documentation", 2025. Overview of ISO 27001, SOC 2, and regional data residency controls on Azure and Microsoft 365.
- Gartner, "Reduce vendor lock in risk in SaaS procurement", 2024. Framework for evaluating data portability and integration persistence in enterprise SaaS contracts.
Next Step
Audit the technology behind your verification.
Run the InfoSec readiness scorecard against your current vendor's stack, or review our security posture in full.