Security at SingleStory
Every person sees only what's theirs.
Each builder's homes, teams and buyers are kept separate. Buyers see their own home, Realtors see only their clients' homes, and your team sees what their role needs.
01 — Our approach
Access starts with context.
Being able to sign in does not mean being able to see every record. SingleStory decides what a person can reach from the relationships around them — the organization they belong to, where they sit in that organization, their role, the homes they are assigned to, their relationship to a buyer, and the invitation that granted access in the first place.
SingleStory is designed to keep builder organizations, teams, buyers and home records appropriately separated while giving each authorized person access to the information they need. Security is built into how the platform handles organizations, roles, homes and public access — not added as a marketing layer afterward.
Organization
Builder A
- Region
- Division
- Community
- Home record
Sales · Construction · Closing · Buyer
Organization
Builder B
- Division
- Community
- Home record
Sales · Construction · Closing · Buyer
Least necessary access
People receive the information appropriate to their role and their assignments, not everything the organization holds.
Tenant separation
One builder's information does not become another builder's information.
Buyer-safe views
Buyers receive information intended for the buyer experience, not the builder's internal operations.
Explicit public boundaries
Only intentionally public marketing pages and forms are reachable without signing in.
02 — Multi-tenant architecture
Each builder operates inside its own boundary.
SingleStory is multi-tenant by design. A builder organization can be structured as a tree — with optional regions and divisions beneath it, communities inside those, and a shared record for each home. Access follows that structure.
- Users operate inside their own builder's context.
- Regions and divisions can have scoped visibility rather than organization-wide visibility.
- Someone authorized for one division does not automatically gain access to unrelated divisions.
- Unrelated organizations do not share access, and being higher in the tree does not by itself grant access below it.
Builder
The organization boundary itself.
Region
Optional, where a builder is organized that way.
Division
Operating groups inside the builder.
Community
Where homes are built and sold.
Home record
One home, and the people responsible for it.
Role-scoped access
Different responsibilities require different access.
A role in SingleStory is not a label on a profile — it determines the information and the actions a person receives.
Buyer and co-buyer
Their own home: progress, buyer-safe updates and photos, appointments, their team, appropriate documents, financing and closing context, and what is needed from them next.
Sales
The buyer relationships and homes they are responsible for inside their organization.
Construction
The homes they are assigned to, and the progress they share from the field.
Realtor
Transaction-appropriate information for their client's home — not builder-wide internal operations.
Outside lender
Scoped to the homes they are assigned to as an external participant. Lender access does not make a lender part of the builder's staff.
Closing
The closing date and the buyer-safe documents they own.
Leadership
Oversight across the part of the organization they are responsible for.
Platform administration
Reserved for authorized platform operations, separate from any builder's staff roles.
Conceptual by design. SingleStory does not publish its internal permission matrix.
03 — Buyer privacy
Buyers see the home journey. Not the builder's internal workspace.
The buyer experience is a deliberately separate view of the same home, not a window into the builder's operations.
Buyer-appropriate
- Construction progress and stage
- Updates written for the buyer
- Photos shared with the buyer
- Appointments and scheduling
- Their team and how to reach them
- Documents intended for the buyer
- Financing and closing status
- What is needed from them next
Internal or restricted
- Internal staff notes and coordination
- Other buyers and other homes
- Management-only oversight views
- Internal operational detail
- Documents held by the lender
- Anything outside their own home
04 — Identity & access
Access is intentional.
Nobody signs themselves up into a builder's organization. Access arrives through a relationship someone authorized created.
- Authenticated experiences require authentication; there is no anonymous route into a builder's records.
- Staff access comes through organization membership and an invitation from someone with authority to send it.
- Buyer and co-buyer access is tied to the specific home they are buying.
- External participants such as Realtors and outside lenders are scoped to the home they were added to.
- An invitation can only be accepted while it is still pending, and access that has been removed is no longer valid.
SingleStory does not currently offer single sign-on, SAML, SCIM provisioning or enforced multi-factor authentication. These are enterprise identity items on the roadmap, and we would rather say so than imply otherwise.
See it in the product
Access is managed in the product, and changes are recorded.
- People
- staff, buyers and Realtors by role
- Access
- set per role and per home
Product screens from our demo builder · fictional sample data.
05 — Application security
The public site and the authenticated platform are intentionally separated.
Controls in place today, described at the level that is useful without teaching someone how to attack the platform.
Row-level access rules
Every application data table has row-level security enabled in the database, so authorization is enforced where the data lives rather than only in the interface.
Guarded privileged operations
Elevated operations are restricted to authorized callers. An organization administrator cannot grant themselves platform-level authority.
Browser security headers
Every response carries a content security policy, strict transport security, framing protection, MIME-sniffing protection, a referrer policy and a permissions policy.
Restricted URL schemes
Stored links are validated before they become clickable; script, data and other unsafe schemes are rejected, as are links that quietly leave the origin.
Upload controls
Uploads are restricted by file type, kept inside the organization and home they belong to, and unsanitized SVG is not accepted on image upload paths.
Sandboxed template previews
Builder-authored email templates are previewed inside a sandboxed frame rather than rendered into the application page.
06 — Public surface
Anonymous access is limited to what is intentionally public.
The public website exists to be read by anyone. The product does not.
- Marketing pages and public content are intentionally public.
- A small number of forms — a demo request, a conversation request — are intentionally open, and they write only to their own request records.
- Product records require authentication and authorization; there is no anonymous read path into a builder's homes, buyers or documents.
- Endpoints that external systems call verify the caller inside the handler rather than relying on the URL alone.
07 — Data handling
Collect what the experience needs. Limit who can use it.
- SingleStory stores the information required to run the home journey: the home, the people around it, progress, appointments, documents, and the status of financing and closing.
- Access to that information is determined by organization, role and relationship — the same rules the product uses everywhere else.
- Builder and buyer information is not sold, and is not made available to advertisers.
- Production access is limited to authorized platform operations.
SingleStory relies on established infrastructure and service providers for parts of the platform. Vendor security and data-handling practices form part of the platform's ongoing security review. A provider's own certifications do not certify SingleStory.
Formal retention schedules, deletion timelines and data-region commitments are being documented as part of the readiness work below, and are agreed contractually rather than claimed here.
Compliance readiness
Strong controls first. Certification when it is earned.
SingleStory is not currently SOC 2 certified.
As SingleStory prepares for larger enterprise deployments, formal SOC 2 readiness and the supporting operational program are part of the security roadmap. We do not publish a certification we do not hold, and we do not publish an audit date we have not scheduled.
In place today
- Multi-tenant isolation following the builder hierarchy
- Row-level access rules on every application data table
- Role-scoped authorization, including scoped external participants
- Authentication required for every product experience
- Invitation-based access with removal
- A deliberately narrow public surface
- Browser security headers on every response
- Upload and stored-link restrictions
- Tests that cover access, isolation and these protections
Ongoing readiness work
- A formal written security-policy set
- Documented incident-response procedures
- Expanded monitoring and log management
- Vendor and security governance program
- A defined vulnerability-management process
- Independent security testing
- Enterprise identity: single sign-on and enforced multi-factor authentication
- SOC 2 readiness and the supporting evidence program
These lists are maintained as two lists on purpose. Nothing moves to the left column until it is actually in place.
08 — For builder technology teams
Need a deeper review?
For builders evaluating SingleStory, we can walk through the current security architecture, access model, data boundaries and readiness roadmap in more detail with your technology, IT, security, procurement or legal teams.
- Tenancy and organizational isolation
- Authorization and role model
- Buyer privacy boundaries
- Public surface and endpoint exposure
- Infrastructure and service providers
- Implementation and testing practices
- Compliance roadmap and timing
A marketing page is not a security questionnaire, a DPA, a penetration-test report or contractual security terms. Those belong in the evaluation itself.
Enterprise evaluation
Let's walk through it with your team.
We're glad to take your technology, security, procurement or legal team through the access model, data boundaries and readiness roadmap in detail.