01Document control

This is the canonical Information Security Policy for ListedRight, Inc. It is owned by the Chief Technology Officer, approved by the Board of Directors, and reviewed annually with interim updates as material changes occur.

02Purpose and scope

Purpose

This policy establishes the information security requirements for ListedRight, Inc. It defines how the company protects the confidentiality, integrity, and availability of customer data, employee data, and company information assets. The policy applies to all systems, networks, applications, data, and personnel.

Scope

This policy applies to all ListedRight employees, contractors, advisors, and authorised agents; all ListedRight services (listedright.ai, the iOS and Android applications, the marketing website, and supporting infrastructure); all customer data; all third-party services, sub-processors, and vendors handling ListedRight data; and all endpoint devices used to access ListedRight systems.

Framework alignment

This policy is aligned with the SOC 2 Type 2 Trust Services Criteria (Security / Availability / Confidentiality) and ISO/IEC 27001:2022, including the Annex A control set. ListedRight is currently building toward certification under both frameworks; the controls described below are in operation or in active implementation in the interim.

03Information security governance

Accountability for information security is concentrated at the executive level and pushed into the day-to-day operating cadence of the engineering organisation.

Roles and responsibilities

Cadence

• ·Annual — full policy review and reapproval by the Board.
• ·Quarterly — risk-register review by the CTO and access-control review (§ 6.6).
• ·Monthly — vulnerability-scan review and sub-processor status check.
• ·Continuous — incident monitoring, log review, and threat intelligence.

Exceptions

Policy exceptions require written approval from the CTO. Each is documented in the security exception register with requestor, reason, compensating controls, expiration, and review date. Exceptions older than 12 months are reviewed for permanent policy update.

04Risk management

ListedRight performs information security risk assessments annually as part of the policy review, when material changes occur (new product features, new sub-processors, organisational changes, significant incidents), and before any high-impact change. Each identified risk is evaluated for impact and likelihood and given a treatment plan.

Risk treatment follows the four standard responses — mitigate, transfer, avoid, accept — with treatment decisions, owners, and target completion dates recorded in the internal risk register. The CTO reviews the register at least quarterly.

05Asset management and data classification

Asset inventory

ListedRight maintains an inventory of production systems and services, code repositories, endpoint devices, cloud accounts and infrastructure, sub-processors and third-party services, and the customer data classifications and locations associated with each. The inventory is reviewed quarterly.

Data classification

Data is classified into four levels:

Customer photograph handling

Customer-uploaded photographs are classified as Confidential. The rules:

• ·Photographs are processed solely to deliver the enhancement service.
• ·Customer photographs are never used to train ListedRight’s AI models or any third-party AI model.
• ·Retained for 30 days from upload on a rolling basis, then automatically and permanently deleted. The unmodified original is also saved to the customer’s phone at the moment of capture, independent of our retention window.
• ·Customers may delete individual photographs or all their photographs on demand from within the application.
• ·Photographs are encrypted in transit (§ 7.1) and at rest (§ 7.2). Internal access is logged and restricted to legitimate operational purposes.

Retention

Acceptable use

All personnel follow the Acceptable Use Policy: company-issued or approved devices for ListedRight work, no sharing of authentication credentials under any circumstances, no installation of unauthorised software on systems handling Confidential or Restricted data, no use of personal email accounts for ListedRight business.

06Access control

Identity & authentication

Every individual with access to ListedRight systems has a unique identifier. Shared accounts are prohibited except for designated service accounts under tight controls. All production systems require multi-factor authentication for every employee, contractor, and administrator — no exceptions — and Single Sign-On for all internal SaaS where SSO is available.

Password requirements (where password login is retained): minimum 12 characters, no reuse of the previous 12, strength validated at creation, rotation only on suspected compromise. Customer-facing authentication on listedright.ai uses bcrypt or Argon2 hashing, requires email verification, supports password-reset via email link, and offers SSO / SAML on the brokerage tier.

Authorization

Access follows the principle of least privilege. Permissions are assigned to roles, not individuals (RBAC). New role definitions require CTO approval. Privileged access — admin to production, database root, cloud account root, repo admin — is granted only when required by role, time-limited where technically feasible, logged with username/target/action/timestamp, and reviewed quarterly.

Customer access controls

Each customer has access only to their own data. Brokerage-tier accounts have admin roles that manage seats within their organisation. Assistant Seats on Listing Pro can access their primary user’s photos but cannot manage billing or account settings. Cross-customer access is technically impossible at the data layer (tenant isolation).

Access reviews

• ·Quarterly — all employee and contractor access reviewed for continued necessity.
• ·On role change — access updated to match new responsibilities; previous access revoked.
• ·On termination — all access revoked within 4 business hours of separation.
• ·Continuously — privileged-access logs reviewed for anomalies.

07Cryptography

Data in transit

TLS 1.3 is required for all production traffic. TLS 1.2 is permitted only for legacy compatibility where unavoidable; TLS 1.0 and 1.1 are prohibited. All public-facing endpoints (listedright.ai, app.listedright.ai, api.listedright.ai) enforce HTTPS with HSTS. Certificates are managed via automated certificate management. Internal service-to-service traffic uses mutual TLS where supported.

Data at rest

Customer data is encrypted at rest with AES-256-GCM. Database storage uses the cloud provider’s managed encryption (AWS RDS encryption). Object storage (customer photographs) is encrypted with AES-256. Backups are encrypted with the same standards. Keys are stored in a managed KMS, never in code repositories or application configuration.

Key management

Encryption keys are managed via a cloud KMS, rotated annually at minimum and immediately after suspected compromise. Access to keys is restricted to the minimum set of service accounts required; every access is logged. Master keys are never extracted from the KMS.

Cryptographic agility

Cryptographic primitives are isolated in code so they can be upgraded without major refactor when standards evolve. Deprecated algorithms (SHA-1, MD5, 3DES, RC4) are not used for any security-relevant function.

08Physical and environmental security

Cloud infrastructure

ListedRight operates on Amazon Web Services. Physical and environmental security at the data-centre level is delegated to AWS, whose facilities meet SOC 1/2/3, ISO 27001 / 27017 / 27018, PCI DSS Level 1, and FedRAMP Moderate. ListedRight does not operate its own data centres and ListedRight personnel do not have or require physical access to AWS facilities.

Remote-first workspace

ListedRight operates as a remote-first organisation. No physical office is maintained at the effective date of this policy. Remote workspace requirements: endpoint devices must be password or biometric-protected, not left unattended in public spaces, and sensitive customer data may only be accessed from approved devices.

Endpoint security

All employee and contractor endpoint devices run full-disk encryption (FileVault, BitLocker, equivalent), apply OS patches within 14 days of release (critical patches within 72 hours), carry an EDR agent, auto-lock after a maximum of 10 minutes inactivity, and support remote wipe for company-issued devices.

09Operations security

Logging & monitoring

Production systems generate logs for authentication events, authorisation decisions, administrative actions, data access on Confidential and Restricted data, system errors, network connections, cryptographic operations, and configuration changes. Logs are centralised in a managed logging service, tamper-evident, retained for at least 12 months (incident-relevant logs for 7 years), and reviewed continuously via automated alerting.

Vulnerability management

Continuous: dependency scanning in CI/CD on every commit, container scanning for production deployment artifacts, external scans of the production attack surface monthly, third-party penetration testing annually, and a published vulnerability disclosure programme via the form at /security and /.well-known/security.txt.

Remediation SLAs (CVSS-based, adjusted for actual exploitability and business impact):

Anti-malware & malicious code

Endpoints run EDR / anti-malware with real-time scanning. Production servers run minimal OS images with only necessary software installed. All third-party code is reviewed via SCA before introduction. Email gateways provide spam filtering and malicious-attachment scanning.

Backup & recovery

Database backups: continuous transaction-log shipping plus daily full backups. Object storage: cross-region replication where the cloud provider supports it. Backups encrypted (§ 7.2) and retained 30 days for point-in-time recovery; longer-term archival as compliance requires. Backup restoration is tested at least quarterly with a sample dataset.

Recovery objectives: RPO 1 hour for the application database, 24 hours for object storage; RTO 4 hours for the application, 24 hours for full service restoration.

10Network and communications security

ListedRight operates within a cloud VPC with public subnets for ingress, private subnets for application tiers, and isolated subnets for databases and KMS. Network ACLs and security groups follow least-privilege rules. Databases and application servers have no direct public access. Outbound traffic is restricted to required services.

A web application firewall protects public-facing endpoints against OWASP Top 10 attack patterns and bot traffic, with rate limiting per IP and API key. DDoS protection is provided by the cloud edge (AWS Shield Standard at minimum, Advanced for production). All ListedRight email domains have SPF, DKIM, and DMARC (`p=reject` once domain reputation is established).

11AI and model governance

AI is core to the product, so it gets its own section even though SOC 2 and ISO 27001 do not name it as a category.

Model usage

ListedRight uses a third-party generative AI model for photo enhancement. Customer photographs are sent to the model provider for processing and returned as enhanced outputs. The sub-processor agreement with the AI model provider specifies that customer data is processed only for the purposes of returning enhancement output, prohibits use of customer data for the provider’s model training, includes deletion timelines aligned with this policy, and carries security commitments at parity with this policy.

Prompt & output safety

Customer photographs are wrapped with prompts engineered for real-estate listing enhancement. The prompt library is versioned and reviewed for output safety (no enhancement producing misrepresentative content), compliance (alignment with NAR Articles 2 & 12 and applicable state disclosure laws via the automatic disclosure tag — see § 11.4), and quality (output meeting MLS submission standards).

AI disclosure tagging

All enhanced photos are tagged with an AI-enhancement disclosure aligned with the NAR Code of Ethics Articles 2 and 12, California AB 723, Wisconsin Act 69, and equivalent state laws. Full details live in the AI Disclosure Statement at /ai-disclosure.

Model monitoring

The AI pipeline is monitored for latency (10-second processing target), error rates and model failures, output volume and resource consumption, and anomalous prompt patterns (defence against prompt-injection attempts).

12Secure development and change management

Secure software development lifecycle

Significant features pass a security review at design time. Implementation follows secure coding standards. Every code change deployed to production requires at least one peer review approval, a passing automated test suite, and a passing dependency vulnerability scan. Pre-commit hooks and CI checks prevent secrets being committed to source. Self-merge of production-bound changes is prohibited.

Change management

Standard changes (routine deployments via CI/CD) are pre-approved by virtue of meeting the SSDLC requirements. Major changes (infrastructure, database migrations, new sub-processors) require CTO approval before implementation. Emergency changes (security patches) may proceed with post-hoc documentation and CTO notification. All changes are logged with description, approver, deployment timestamp, and deployer.

Secrets management

API keys, database credentials, encryption keys, and third-party tokens are stored in a managed secrets service, injected at runtime, rotated annually at minimum, inventoried, and never committed to source repositories. Production data is never used in development or staging environments — synthetic test data only. Customer photographs from production never appear in non-production environments.

13Third-party and supplier management

Before any new sub-processor is engaged, ListedRight reviews their security posture (SOC 2, ISO 27001, or equivalent), data processing terms (DPA, sub-processor list, retention practices), compliance posture (CCPA / CPRA, GDPR where applicable, sector-specific), incident history, and business stability. Approval requires CTO sign-off. The risk review is repeated annually.

A Data Processing Agreement is in place with every sub-processor that handles customer data. The DPA specifies categories of data, purpose of processing, security obligations, breach notification, deletion, and audit rights. The current sub-processor inventory is published on this page above; material additions are announced via email to brokerage customers 30 days before activation.

Customer data is not shared with third parties outside the sub-processor list except with explicit customer consent, to comply with valid legal process, or to protect ListedRight, its customers, or others. In all cases of compelled disclosure, ListedRight notifies the customer where legally permitted.

14Human resources security

Pre-employment

Before granting access to ListedRight systems, the employment agreement is signed (including confidentiality clauses), IP assignment is confirmed, and a background check is completed where legally permitted and where the role warrants — required for any role with access to Confidential or Restricted data.

Awareness training

All employees and contractors complete onboarding security training within 30 days of access being granted, an annual refresher thereafter, and targeted training when roles change or specific risks emerge. Training covers phishing recognition, password hygiene, data handling, incident reporting, and the AI / customer-data specifics.

Termination & role change

On termination (voluntary or involuntary): system access is revoked within 4 business hours of separation, company-issued endpoints are returned and wiped, authentication credentials are deactivated, and the final access review is documented. On role change, access is re-baselined to the new role and permissions that no longer apply are revoked within 5 business days.

15Incident response

Classification

Process

1. 1.Detect — alerting, log review, vulnerability reports, user reports.
2. 2.Triage — initial classification and ownership assignment within 1 hour of detection.
3. 3.Contain — isolate systems, revoke credentials, limit further damage.
4. 4.Eradicate — remove the cause (patch, malware removal, session termination).
5. 5.Recover — restore normal operations.
6. 6.Lessons learned — post-incident review within 14 days.

Breach notification

In the event of a confirmed data breach affecting customer data: customers are notified without unreasonable delay and not later than 72 hours from confirmation where the breach is likely to result in a risk to the rights and freedoms of natural persons. Regulators are notified where required by law. Sub-processors are notified where the incident affects shared infrastructure. A public statement is issued where the incident is material and customer-facing. The CTO is the designated lead for breach response.

Post-incident review

Every SEV-1 and SEV-2 incident produces a written post-incident review: timeline, root cause, customer impact, remediation actions, recommended changes to controls or policy. Reviews are reviewed by the CTO and any board-level oversight body, and inform the next quarterly risk review.

16Business continuity and disaster recovery

ListedRight maintains a business continuity plan covering personnel availability (cross-training, on-call rotation), critical vendor dependencies and alternates, communications during a disruption, and the order of restoration for critical business functions.

Disaster recovery objectives are stated in § 9. DR procedures cover loss of the primary cloud region, loss of access to critical sub-processors, loss of the source code repository, and loss of key personnel. DR tests are performed annually at minimum, with results documented and lessons applied.

17Compliance and audit

Legal & regulatory

ListedRight monitors and complies with US federal and state privacy laws (CPRA and equivalents), real-estate AI disclosure laws (California AB 723, Wisconsin Act 69, others as enacted), the NAR Code of Ethics for licensed real-estate professional customers, state consumer-protection laws, and tax / financial recordkeeping requirements.

Internal & external audit

Internal audits of security controls are performed annually for the full policy, with targeted audits for specific control families when material change occurs. External audit and certification under SOC 2 Type 2 and ISO/IEC 27001:2022 are in progress; certification status will be reflected at the top of this page when issued.

Customer audit rights

Brokerage and enterprise customers may request a current copy of this Policy, the current sub-processor inventory, the most recent SOC 2 report (once issued, under NDA), ISO 27001 certification documentation (once issued), and specific control evidence relevant to their use case (subject to confidentiality and reasonableness). Requests are processed via the form linked above.

18Policy maintenance

This policy is reviewed annually by the CTO with formal reapproval by the Board of Directors. Interim updates are issued when material changes occur. Material changes increment the major version (e.g., 1.0 → 2.0); minor edits increment the minor version. The current version is the canonical source; superseded versions are archived for audit.

Upon publication and after material updates, this policy is distributed to all employees and contractors, acknowledged by each individual via signed receipt or equivalent electronic acknowledgment, and made available to authorised external parties on request.

19Appendix A · SOC 2 Trust Services Criteria mapping

20Appendix B · ISO/IEC 27001:2022 Annex A mapping