Compliance vs. Security: A Vendor Security Assessment Framework for Real Estate Lending Technology

Real estate and construction lending IT and procurement teams evaluating technology vendors routinely conflate compliance with security. The two are related but they do different things. Missing that distinction creates procurement delays and, in the worst case, approves software that passes the audit checklist but fails the real security test.

TLDR: Compliance is evidence that a vendor met a defined standard at a point in time. Security is the ongoing practice of protecting systems and data from actual threats. For real estate and construction lending IT and procurement teams evaluating cloud-based software, treating one as a proxy for the other is the single most common mistake in vendor security review.

A serious vendor invests in both. Built’s compliance program and security program are designed to operate together. Compliance attests to controls at a point in time. Security operates and improves those controls every day. This article gives IT and procurement teams a seven-question framework for evaluating real estate and construction lending technology vendors, and shows what Built’s compliance and security stack looks like in practice.

What Compliance Proves 

Compliance proves that a business met the control requirements of a defined framework over a tested period. A current SOC 2 Type II report, for example, tells a buyer three things. The vendor had controls in place. An independent auditor tested those controls over a period of time, typically six to twelve months. The auditor did not find material exceptions.

That is meaningful information. It is also a point-in-time attestation by design. Audit cycles run on a fixed cadence. Threat landscapes do not. Between audit windows, new vulnerabilities emerge, services expand, and upstream providers introduce new risks no single certification can predict in advance.

This is why a strong vendor pairs current attestations with ongoing security operations. At Built, the SOC 2 Type II audit is one input. Continuous vulnerability scanning, real-time monitoring, incident response procedures, and an internal security team operate on top of it, every day, in between audit cycles. Lenders evaluating Built receive the audit attestation and visibility into the operational program that backs it.

For lending IT and procurement teams, the practical takeaway is that audit reports are a baseline. The vendors worth trusting build well above the baseline and document the work transparently.

What Security Proves (and What Compliance Alone Misses)

Security is the ongoing practice of protecting systems and data from actual threats, regardless of whether any particular audit framework has been applied. A mature security program treats compliance as a baseline and actively invests beyond it.

Security posture is measured differently than compliance posture. It covers how the vendor detects new threats in real time, how fast it responds to incidents, how it manages its own supply chain, and how its people and process choices reinforce or weaken the technical controls. None of those are captured in a single attestation.

For a bank or nonbank lender doing vendor due diligence, the practical question is not “is this vendor compliant,” but “is this vendor secure across the conditions we actually operate in.” The two overlap. They are not the same.

The CIA Triad

Most bank security teams frame this with the CIA triad: confidentiality, integrity, and availability.

Confidentiality means only authorized parties can access the data. Integrity means the data has not been altered or tampered with. Availability means authorized parties can access the data when they need it. Compliance standards define how those three attributes should be protected. Security is whether they are being protected today.

How to Evaluate a Real Estate and Construction Lending Technology Vendor

A rigorous vendor security assessment starts before any audit reports get exchanged. The goal is to understand what the vendor is actually doing, how it touches the lender’s environment, and where risk can enter or leave. Seven questions define the scope. Every procurement review should start here.

1. What services does the third-party provide?

Define the scope of the engagement in operational terms. What business process does the vendor own or touch? Which internal teams depend on it? A vendor with narrow, well-defined scope is easier to assess than one whose footprint is ambiguous.

What Built’s answer looks like: Built’s scope in a lender engagement is explicitly documented by the specific service in use and provided as part of the procurement package.

2. How do employees access the service?

Document the access path. Is the service accessed through a browser, a VPN, a mobile app, or an API? Is access restricted by IP, by device, or only by credential? The access path determines what the rest of the security review should cover.

What Built’s answer looks like: Built supports access through customer-managed identity providers and can be restricted by the lender’s own IP allowlist and device posture requirements.

3. What authentication methods are used?

Confirm MFA is enforced, SSO is supported, and session management aligns with the lender’s own policy. Authentication is the single point of failure most exploited in vendor breaches. A vendor that treats MFA as optional should not pass a construction lending security review in 2026.

What Built’s answer looks like: Built supports centralized identity management with Single Sign-On (SSO) and multi-factor authentication (MFA), with session policies configurable by the lender.

4. What permissions will users have?

Review permission levels, provisioning workflows, and the process for removing access when staff change roles or leave. Vendor permission models should support least-privilege and role-based access control (RBAC) as defaults, not as premium add-ons.

What Built’s answer looks like: Built uses role-based access management with least-privilege defaults and approval workflows so no single individual can authorize high-risk actions unchecked.

5. Will it integrate with existing systems?

Map the data flows. Which of your systems will the vendor read from or write to? What data crosses the boundary, and in what direction? Integration surface is where scope creep and unmonitored risk most often enter.

What Built’s answer looks like: Built documents every integration point and data flow in the architecture review that accompanies the security package. Integrations are scoped to the specific lender systems and data elements required by the engagement.

6. How does the technology interface with current infrastructure?

Go one layer deeper than integration points. Where is the vendor’s service hosted, and which data centers carry it? What encryption protocols are used for data in transit and at rest? Can the vendor demonstrate network segmentation between customers?

What Built’s answer looks like: Built operates on SOC 1, SOC 2, and ISO 27001 certified data centers, with strong encryption for data in transit and at rest, and documented network segmentation between customer environments.

7. What data elements are included?

List the specific data elements in scope. For construction lending, that typically includes non-public financial information, loan documents, wire instructions, borrower data, contractor payment data, and lien waivers. Every element should have a documented handling policy.

What Built’s answer looks like: Built documents every data element by product line and explains how each is transmitted, processed, and stored, including retention policies and data residency.

Once those seven are answered, the buyer can reasonably scope which audit reports, attestations, and policy documents the vendor should provide. Without that scoping, vendor security reviews turn into generic questionnaires that slow procurement without improving security.

Built’s Compliance and Security Stack

Built approaches compliance and security as complementary practices. The following controls are in place today, each subject to independent audit or continuous monitoring.

• SOC 2 Type II (annual audit). Built maintains SOC 2 Type II compliance, audited annually under AICPA/SOC standards by a qualified independent third-party firm. The audit tests security controls and confirms the program continues to meet defined standards.
• SOC 1 Type II (annual audit). Built maintains SOC 1 Type II compliance, also audited annually under AICPA/SOC standards.
• PCI compliance. Payment processing on the Built platform is orchestrated through Modern Treasury, with BMO and JPMorgan Chase as bank partners. All parties in the payment flow are PCI compliant.
• AML policy. Built maintains an AML policy with third-party monitoring for compliance with federal AML requirements.
• Multi-factor authentication and role-based access control. MFA is enforced on all administrative access. RBAC with least-privilege defaults governs user permissions. Access rights and permissions are reviewed regularly across infrastructure and systems.
• CCPA. Built’s data handling practices align with the California Consumer Privacy Act (CCPA), supporting customer and consumer data rights under California’s privacy framework.
• NIST alignment. Built’s security program is aligned with NIST security standards and frameworks, covering identification, protection, detection, response, and recovery across the security program.
• Data center certifications. Built’s data centers hold SOC 1, SOC 2, and ISO 27001 certifications, with continuous data backups and multi-region redundancy.

Additional controls

Strong encryption for data at rest and in transit. Comprehensive audit logging to support incident investigation and remediation. Continuous vulnerability scanning across service infrastructure, codebase, and endpoints. 

Secure software development practices aligned with OWASP recommendations. Regular penetration testing performed by external firms and Built’s internal security team. Annual risk assessments. Security awareness training for all employees. A vendor management program covering Built’s own suppliers.

What third-party attestation means for your review

Built’s SOC 1 and SOC 2 Type II reports, along with other security-related documentation, are available through the Built Security Shared Profile after an access request and click-through NDA. Attestation is one input to a security review. It should not replace the seven-question framework above, and it should not replace the lender’s own internal risk assessment.

Shortening the Review Cycle with the Security Shared Profile

Vendor security reviews consume disproportionate time on both sides. Built’s security team publishes a Security Shared Profile that combines the administrative, technical, and physical security documentation most buyers need into a single pre-prepared package. Current and prospective clients can request access after a click-through NDA.

This approach lets IT and procurement teams focus their review time on the questions that are unique to their environment, not on the routine ones every vendor gets asked. For construction lending teams running a procurement cycle under tight timelines, the Security Shared Profile often shortens security review from weeks to days.

For more detail, visit the Built Security Trust Center.

Compliance vs. Security FAQ’s

What does SOC 2 Type II actually prove?

A SOC 2 Type II report proves that a vendor’s controls related to security, availability, processing integrity, confidentiality, and privacy were in place and operated effectively over a tested period, usually six to twelve months. It is an attestation by an independent auditor, not a certification by the vendor. It does not prove the vendor is secure today outside the audit scope, and it does not cover services or controls that were not included in the audit engagement.

Is SOC 2 enough for a financial-services vendor?

For financial-services vendors, SOC 2 Type II is necessary but not sufficient. Banks, credit unions, and nonbank lenders operate under examiner scrutiny that extends beyond SOC 2 scope: AML monitoring, data residency, access governance, incident response, and third-party risk management are all in play. A rigorous review uses SOC 2 as one input among several, alongside the vendor’s own security program documentation, penetration test results, and the lender’s internal risk assessment.

What happens if a vendor is compliant but has a breach?

Compliance and breach are not mutually exclusive. A vendor can hold a current SOC 2 report and still experience a security incident. When that happens, the questions that matter are how fast the vendor detected the incident, how it was contained, how customer data was handled, and what disclosure and remediation obligations the vendor honored. Compliance frameworks define minimum controls. Real-world breach response is measured by outcomes.

How should a lender’s IT team evaluate cloud-based construction lending software?

A lender’s IT team should start with the seven-question scoping framework above: services, access, authentication, permissions, integration, infrastructure, and data elements. From there, request SOC 1 and SOC 2 Type II reports, ISO 27001 certification evidence where applicable, a data flow diagram, penetration test summaries, the vendor’s incident response plan, and the vendor’s own third-party risk management documentation. The goal is to understand not just what the vendor has certified, but how it operates day-to-day under the conditions your portfolio actually runs in.

Does Built make compliance documentation available for procurement review?

Yes. Built publishes a Security Shared Profile that combines SOC 1 and SOC 2 Type II reports, policy documents, and responses to routine security questionnaires into a single pre-prepared package. Current and prospective clients can request access after a click-through NDA, and the Built security team is available to answer any additional questions that are unique to the lender’s environment.