Every “Yes” we claim, and how to check it.

What it means A signed-in person can read only the community’s resident records that their permitted access covers; the database itself, rather than a screen in the application, makes that decision.

How it works in plain terms Row-level security is a database rule that evaluates each individual record before returning it. It is enabled and forced on every protected base table—the underlying database table—within scope: all 11 protected base tables in the resident-data scope (11 of 11). Our application’s own database credentials cannot switch that rule off or bypass it. If a signed-in session tries to read a protected table directly without an allowed record scope, the database engine—the component that stores and returns data—refuses the read.

What HUD asks for HUD’s PII safeguard notice directs PHAs to protect sensitive PII and limit collection and use to authorized purposes; 24 CFR 5.212 requires applicable handling of SSNs, income information, and related data to comply with the Privacy Act. PIH Notice 2015-06 and 24 CFR 5.212 provide the governing context.

How you can verify it In a live demo, ask us to sign in with a permitted user and an out-of-scope user, then attempt both product-screen and direct database-session reads of the same protected resident record. The out-of-scope read should be refused by the database.

What it means Each protected-access event leaves a server-recorded trail that cannot be edited away through normal database access.

How it works in plain terms The access ledger is insert-only: the database engine refuses any attempt to change or delete a recorded event. Each row carries a cryptographic hash—a tamper-evident digital fingerprint—linked to the prior row. A daily anchor fixes the day’s ending fingerprint for later comparison, so changing a row makes the chain disagree with that anchor. Read events are recorded on the server, so the event is logged even when a browser does not volunteer a log message.

What HUD asks for HUD directs PHAs to safeguard PII and prevent or promptly report suspected compromises. An access record that shows who viewed protected information, when, and why supports that responsibility. PIH Notice 2015-06 describes those PII safeguarding and reporting duties.

How you can verify it Ask us to show a protected read, its corresponding ledger entry, and an attempted change or deletion of that entry. Ask us to validate a selected portion of the hash chain against its daily anchor.

What it means A person cannot open protected resident information without identifying the case they are working and declaring the authorized reason for the read.

How it works in plain terms Before information in a protected sensitivity tier is released, the request must carry a case identifier and a declared purpose. The server writes both values into the access ledger with the read event. A request with no purpose is refused; the product does not treat a missing explanation as permission.

What HUD asks for HUD’s PII safeguard notice and EIV guidance limit access to authorized, duty-related use; HUD’s EIV guidance says access to income-verification information should be restricted to people whose duties require it. The Privacy Act’s internal-use exception is likewise limited to officers and employees who need the record to perform their duties. PIH Notice 2015-06, HUD’s EIV Security Guidelines for PHAs, and 5 U.S.C. § 552a set out that need-to-know standard.

How you can verify it In a live demo, ask us to try a protected read with no case or purpose, then repeat it with both. The first request should be denied; the second should produce a ledger entry that shows the case and declared purpose.

What it means Access is decided field by field, not only record by record, so a role sees only the resident details it needs.

How it works in plain terms A centrally enforced field list assigns every resident attribute a sensitivity tier, and the tier controls visibility by role. Taxpayer and bank identifiers are retained as last four digits plus a one-way hash—a value used for comparison that cannot be reversed into the original identifier—not as full numbers. A database trigger, meaning an automatic database check, rejects tier-3 (most restricted) data from a shared database area.

What HUD asks for HUD directs PHAs to collect only the PII needed for the authorized purpose and to safeguard it; 24 CFR 5.212 covers applicable collection, maintenance, use, and dissemination of SSNs and income information. PIH Notice 2015-06 and 24 CFR 5.212 are the relevant HUD and CFR references.

How you can verify it Ask us to compare the same resident record under roles with different permissions, inspect the field registry for a selected attribute, and attempt to place tier-3 data into a shared schema. The prohibited write should be rejected.

What it means Current EIV security training is a condition of protected access, not a reminder shown after access has already been granted. EIV is HUD’s Enterprise Income Verification system.

How it works in plain terms Training currency is evaluated inside the access policy that governs the protected read. When the recorded training expires, the database refuses the protected read until updated training is recorded. This makes a lapsed training record an access stop, rather than an item for a manager to notice later.

What HUD asks for HUD’s EIV guidance requires training before access and says users with EIV access should receive annual security-policy and procedure briefings; HUD materials also state that EIV users must complete security awareness training annually. HUD’s EIV Security Guidelines for PHAs and the HUD Security Administration Manual describe that requirement.

How you can verify it In a live demo, ask us to use an account with current training and one with an expired training record against the same protected read. The expired account should be refused until a current training record is entered.

What it means Opening resident identity or income information requires a fresh second check from an authenticator app, rather than relying only on the sign-in that started the session.

How it works in plain terms Users enroll a time-based one-time passcode (TOTP) authenticator: an app generates a short-lived code that proves the user has the enrolled device. The system asks for that second factor when the user reaches resident identity or income data. It therefore raises assurance at the sensitive action, not only at the first login.

What HUD asks for HUD calls for safeguards appropriate to sensitive PII. In plain English, NIST’s AAL2 concept means the system needs proof of two different authentication factors and gives high confidence that the user controls the registered authenticator. PIH Notice 2015-06 and NIST SP 800-63B’s AAL guidance provide that context.

How you can verify it Ask us to sign in, navigate to a protected resident identity or income field, and show that the second-factor challenge is required at that moment. Then ask to repeat the attempt without the valid app code.

What it means Data is protected while it moves between systems and while it is stored; full taxpayer and account numbers are not stored at all.

How it works in plain terms Connections use TLS—an encrypted connection that protects information while it travels over a network. Stored data uses managed encryption at rest, meaning the storage platform encrypts the data it keeps. Full taxpayer and account numbers are excluded from storage; where an identifier is needed for matching, the system keeps only the last four digits and a one-way hash.

What HUD asks for HUD’s PII safeguards call for protection of sensitive data and direct PHAs to collect only what is needed for the authorized purpose. PIH Notice 2015-06 and 24 CFR 5.212 are the applicable references.

How you can verify it Ask us to demonstrate an encrypted connection, show the storage-encryption configuration evidence available for customer review, and inspect representative protected identifier records to confirm that full numbers are absent.

What it means We do not hold a SOC 2 attestation today, and we will not describe ourselves as if we do.

How it works in plain terms SOC 2 is an independent auditor’s report on selected controls. We have no SOC 2 attestation to offer today. Readiness work is underway; when an attestation exists, we will publish the auditor, examination period, and scope. This candor is itself a control: procurement teams can distinguish demonstrated facts from marketing claims.

What HUD asks for HUD requires PHAs to safeguard PII and prevent or report suspected compromises; it does not turn a vendor’s unverified assurance claim into evidence. PIH Notice 2015-06 is the relevant HUD safeguard notice.

How you can verify it Ask us directly whether we hold a current SOC 2 report. Our answer is no. Ask for the control demonstrations on this page instead, and, if an attestation is later issued, ask for the published auditor, period, and scope.

What it means RentSpire does not claim FedRAMP authorization and does not use adjacent language such as “FedRAMP capable.”

How it works in plain terms FedRAMP is a U.S. government authorization process for cloud services; it is not a general-purpose adjective. No HUD rule requires FedRAMP authorization of PHA vendors. Our security claims are limited to the controls we can demonstrate, rather than implied through a federal-program label we do not hold.

What HUD asks for HUD’s applicable direction is to safeguard PII and use it only as authorized, including the requirements referenced in 24 CFR 5.212; it does not establish a FedRAMP requirement for PHA vendors. PIH Notice 2015-06 and 24 CFR 5.212 are the relevant references.

How you can verify it Ask us whether we claim FedRAMP authorization or any equivalent status. We will answer no and will point you to the specific, demonstrable controls on this page.

What it means This page, together with the mandate band on our public site, is RentSpire’s public safeguard statement and can be attached to a procurement file by URL.

How it works in plain terms It identifies the controls that protect resident information, explains their operation in ordinary language, and links each control to the relevant public rule or guidance. The statement is designed to support a PHA’s review; it does not replace the PHA’s own required notices, policies, or approvals.

What HUD asks for HUD requires applicable handling of SSNs, income information, and related data to comply with the Privacy Act, and it directs PHAs to safeguard PII. 24 CFR 5.212, 5 U.S.C. § 552a, and PIH Notice 2015-06 provide the cited requirements and guidance.

How you can verify it Save or attach this page’s public URL to the procurement file, open the stable links for the controls under review, and ask us to demonstrate any control described here.

What it means This page is the RentSpire trust center: the public starting point for control evidence, citations, and live-verification requests.

How it works in plain terms Each evidence item is independently linkable, uses a plain-English description, identifies the relevant HUD or federal reference, and gives a specific demonstration request. This structure lets procurement teams assess a claim without relying on a logo wall or a blanket assurance statement.

What HUD asks for HUD’s guidance centers on safeguarding PII, limiting its use, and reporting suspected compromise—not on accepting untested vendor assertions. PIH Notice 2015-06 provides the applicable HUD safeguard context.

How you can verify it Use any anchor on this page in your procurement record and ask for the corresponding live demonstration. If an answer cannot be demonstrated, treat it as not established.

What it means RentSpire has no reported security incident.

How it works in plain terms If an incident were identified, the append-only ledger would provide the event timeline as a query: protected reads and their recorded case and purpose can be reviewed without relying on an editable activity log. That record supports investigation and a timely, fact-based response.

What HUD asks for HUD Notice PIH 2026-17 says that, when a cyber incident occurs, a PHA must email HUD’s Cyber Incident Response Team and its local field-office contact no later than 36 hours after the PHA becomes aware of the incident. PIH Notice 2026-17 states that reporting duty.

How you can verify it Ask us to demonstrate an incident-timeline query from a controlled test event and to explain how the resulting record would support your PHA’s own reporting and investigation process.

What it means Our public data provenance page shows where each published field comes from, alongside live pipeline-health and coverage views read from the same database that serves the product.

How it works in plain terms A field’s provenance is its documented origin and transformation path. The public views show pipeline health and coverage from the operational data source, rather than a separately maintained marketing snapshot. This gives a procurement team a current way to trace the basis of a displayed data point.

What HUD asks for HUD’s PII guidance emphasizes using data only for the authorized purpose and protecting it throughout handling. Public provenance does not expose protected resident information; it makes the basis and handling of published, nonresident data reviewable. PIH Notice 2015-06 provides that PII safeguarding context.

How you can verify it Open the provenance page, select a field, inspect its stated origin and transformation path, and compare the live health and coverage view with the value displayed in the product.

What it means Our source status board and estimate page publish the rent-comparison methodology and the nationwide building-level dataset used for estimates.

How it works in plain terms The methodology explains how the system selects and uses comparable buildings; the dataset description identifies the building-level input base. Publishing both allows a PHA to review the method rather than treating an estimate as unexplained output.

What HUD asks for HUD’s PII guidance calls for collecting and using information only as needed for the authorized purpose. The public methodology and source descriptions give procurement teams a way to assess data use without disclosing protected resident information. PIH Notice 2015-06 provides the relevant data-handling context.

How you can verify it Review the source status board and the estimate methodology, then ask us to walk through a sample estimate and identify the published method and source description that support it.

What it means The landing page maintains a dated HUD mandate tracker, supported by a weekly regulation watch; every listed mandate links to its dated HUD notice or Federal Register citation.

How it works in plain terms The tracker makes the source document and date visible beside the mandate statement. The weekly watch checks for new, superseding, or amended HUD and Federal Register materials so the public list can be reviewed against the primary document rather than a stale summary.

What HUD asks for HUD notices can remain in effect until amended, superseded, or rescinded, so a procurement review should use the dated controlling document. PIH Notice 2015-06 and PIH Notice 2026-17 are examples of dated HUD notices.

How you can verify it Open the mandate tracker from the landing page, follow a listed mandate to its dated HUD notice or Federal Register citation, and ask us to show how the weekly watch records a new or superseding source.