Privacy Policy — Siraja

What information Siraja collects, why it is used, who can see it, and how to ask for access, correction or deletion.

Jump to a section

Last updated: 2026-10-25

This Privacy Policy explains how Siraja ("we", "us") collects, uses, stores, and protects personal information through the Siraja property management platform (the "Service").

Siraja is operated by Surjit Singh, sole proprietor, trading as Siraja, registered under India's Udyam registration scheme (Udyam Registration Number: UDYAM-PB-20-0139992), District Industries Centre: SAS Nagar, Punjab.

This policy applies to landlords, property managers, tenants, and any other individual whose personal information is processed through the Service.

If you are a tenant invited to use the Service by a landlord or property manager, please also see "If You Are a Tenant" below. The workspace customer generally decides why tenancy information is entered and is responsible for its accuracy and lawful collection. Siraja provides the Service used to process that information and remains responsible for its own account, security, support, and legal-compliance activities.

1. Who We Are

Siraja is a property and tenancy management platform used by landlords and property managers in India and Canada to manage properties, tenants, leases, payments, and related records. Surjit Singh, sole proprietor trading as Siraja (Udyam Registration Number UDYAM-PB-20-0139992), is the entity responsible for operating the Service.

Roles. For the tenancy and rental records a workspace enters, the workspace's landlord or property manager decides why and how the information is used, and Siraja processes it for them to provide the Service. For account information, billing for Siraja's own plans, security, support and meeting the law, Siraja decides why and how, and is responsible for it.

Contact for privacy matters: support@siraja.in. See Business details and complaints for the operator's contact details and Grievance Officer.

2. What Personal Information We Collect

We collect different categories of information depending on your role. Each category below states why the information is used. This policy is designed with regard to India's Digital Personal Data Protection Act, 2023 ("DPDP Act") and Digital Personal Data Protection Rules, 2025 as their provisions come into force, Canada's Personal Information Protection and Electronic Documents Act ("PIPEDA"), and applicable provincial Canadian privacy laws.

2.1 Account Information (all users)

Name, email address, phone number
Password hash, or Google account sign-in details if you choose to sign in with Google. Siraja does not store your Google password.
Purpose: to create and secure your account, authenticate you, and allow you to use the Service.

2.2 Landlord and Property Manager Information

Business/organization name, property addresses, currency and regional settings
Team member names, emails, and assigned roles within your organization
Purpose: to operate your property management workspace and control access among your staff.

2.3 Tenant Information

Legal name, preferred name, date of birth, phone, email, residential address
Emergency contact name, phone, relationship
Identity-review records. Where a landlord or property manager records that identity evidence was reviewed (e.g. Aadhaar, PAN card, passport, driving licence, voter ID, or other government ID), we record that a document was collected or reviewed, its type, and its review or expiry dates. We do not store the identity document number itself. Siraja Documents does not accept identity-document files or identity numbers either: please do not upload Aadhaar, PAN, passport, driving licence or other identity evidence there (see Section 6).
Employment status, employer name, job title, and self-reported annual income, where a landlord chooses to collect this for tenancy screening
Guarantor/co-signer name, relationship, contact details, and address, where applicable
Purpose: to support tenant onboarding, identity verification, lease creation, and legally required tenancy record-keeping. This information is entered by your landlord or property manager, or by you directly if invited to a self-service tenant portal.

2.4 Financial and Payment Information

Rent charges, payment records, payment method descriptions (e.g. "bank transfer"), amounts, dates, and running balances
Deposit records
Important: Siraja does not process, move, or hold your money. Landlords record payments they have received through their own separate banking arrangements. The Service is a record-keeping and communication tool, not a payment processor.
Purpose: to maintain an accurate rent ledger, arrears record, and financial history for the tenancy.

2.4A Billing Information for Siraja's Paid Plans

For a workspace that starts a free trial or subscribes to a paid plan: the plan, trial and subscription dates, the amounts charged, Siraja's receipt numbers, and the payment, invoice, subscription and refund references our payment provider gives us
Which workspace and which account started a free trial, so that neither can start another. And, to stop the same person starting further free trials from other accounts, a keyed one-way fingerprint of the email address of the person who starts a trial — not the address itself. It is made with a secret key kept outside our database, so the fingerprint alone cannot be reversed or checked against an address, and it is erased 24 months after the trial started
When we tell a workspace Owner in advance that plan allowances will apply: when the notice was delivered, or failed to be, and the message reference that shows it
When an Owner asks for a refund of Siraja's own charges: the time the request reached us, who asked, and any note added to it; for a request by email, the time the email reached us
The legal name an Owner records for receipts (the person or business that buys the subscription), the Siraja Account Number, and the seller's details printed on each receipt as issued. We do not ask for a postal address for receipts
We do not receive or store card numbers, UPI IDs, bank account details or other payment credentials. You give those to our payment provider, Razorpay, directly.
Purpose: to bill for Siraja's paid plans, issue receipts, apply each plan's allowances, handle cancellations and refunds, and meet accounting and tax obligations.

2.5 Lease and Occupancy Information

Lease start/end dates, participants on a lease, move-in/move-out history, which space or unit is occupied
Purpose: to maintain an accurate legal and operational record of tenancy arrangements.

2.6 Maintenance and Inspection Information

Maintenance requests, descriptions, categories, vendor details, inspection records, and any photographs or files attached to a request or an inspection (see Sections 2.9 and 6)
Purpose: to manage property upkeep and safety records.

2.6A The Resident Portal

What a resident can send. A resident with a current stay can report a repair, ask the property team a question, ask for a record to be corrected, message the property team, report a payment they made, and read documents the property team has chosen to share with them. A resident whose stay has not started yet (a planned stay) can ask the property team questions about their move, their lease or a document, but cannot report a repair or ask for a correction. A resident whose stay has ended can still follow up on their earlier requests and ask for a correction to their own records, and can ask about a charge, a payment or a document.
A repair report holds what the resident writes (a title, a description, where in the home it is, when they are available and any note about access), a category and an urgency the resident chose, and up to three photographs (JPEG or PNG, each at most 5 MiB). The urgency is the resident's own view and does not set the property team's priority. Saying when they are available is a proposal, not permission to enter. Where Documents or photograph uploads are switched off, a repair can still be reported in words and the portal says photographs are unavailable. A photograph must be a JPEG or PNG of at most 5 MiB, no more than 9,000 pixels on a side and 36 million pixels in all, and subject to the workspace's storage and upload limits (Section 6). The file as uploaded is what is scanned for malware; the copy that is stored and shown is the same photograph with its camera information (location, device, time) removed. The scan reduces risk; it cannot promise that every harmful file will be detected, and a photograph that fails a check or cannot be scanned is not made available.
A question or correction request holds the resident's words, the record it concerns (a charge, a payment, a document, or none) and the property team's response. A correction request changes no record by itself; a record changes only if the property team changes it with its own tools, and the request then shows whether it was corrected, explained without change, or declined with a reason.
Who sees it. The resident sees their own reports, requests and conversations. People in the workspace see them only if their role and their access to the property concerned allow it. A reply the property team marks as public is shown to the resident; an internal note is never shown to the resident. A repair, question or correction request a resident starts is private to that resident and the property team members who may handle it; other residents, including those on the same lease, cannot see it. Conversations the property team started about a lease keep working as they always did: everyone on that lease can read them. A team member sees a resident's request only if their role holds the permission for what it is about (payment records for a charge or payment, documents for a document, resident records for a correction of personal details, otherwise leases) at that property.
Documents shared with a resident. A resident sees a document only after a team member who may manage documents has shared one named version of it with that resident; a later version is never shared automatically. Identity documents and highly restricted documents cannot be shared. Withdrawing a share stops every new download at once; a download link already issued can keep working until it expires, which is about two minutes and never more than five. Withdrawing a share does not delete the document or its other versions.
Payments a resident reports. A resident saying that money was sent records their report; it does not reduce what is owed until a team member confirms the money arrived.
Team members assigned to a resident's repair. A team member given the narrow role for assigned work (Field Worker) cannot see leases, residents, payments, documents or other repairs. For one repair that a resident reported and that is assigned to them, they see the resident's own words about it (title, description, category, urgency, availability and any note about access), the property team's conversation about it with the resident, and the photographs the resident attached to it. They do not see the resident's name, email address, phone number or any other record of theirs. They can reply to the resident in that conversation, which the resident reads, and write internal notes, which the resident does not. This access is checked each time something is requested. It stops when the repair is given to someone else, or is closed or declined, or when the person is suspended, removed, or no longer has access to that property; the next request is refused, no new photograph link is issued, a message about that repair that was waiting to be emailed to them is cancelled, and a live conversation window left open stops receiving messages. Each photograph link issued to an assigned team member is recorded in the workspace's audit trail with who asked, which document and which repair.
Email. The portal can email a resident a short message that something needs their attention, with a link and without the details. Residents can choose their notification preferences in the portal.
Siraja support. Section 2.8 states what Siraja support may see and do, and when. It does not list repair reports, requests, photographs or conversations among them, so a support case does not give Siraja access to them.
Purpose: to let a resident tell the property team about a problem or a mistake in their records, and to let the property team and the person doing the work respond.

2.7 Technical Information

IP address, device/browser type, log data, session identifiers
If the Service fails unexpectedly while handling a request, it may show you an Incident ID (for example INC-7K2Q-9MXD). Under that ID we record only what we need to find the failure: when it happened, which operation failed, the kind of error, the software version and, where your request had already been authorized for a workspace, which workspace. That record, and the server log entry for the failure, never hold what you entered or sent, the text of any message, or your email or IP address. Incident records are deleted after 90 days.
If the app itself fails in your browser while you are signed in to a workspace, a short technical description of the error (at most 500 characters, which can occasionally repeat text that was on the page), the address of the page you were on, the time, and which account was signed in are recorded for that workspace. The people who manage the whole workspace can see these reports. 90 days after a report was first recorded, its description, the page address, any request reference and which account was signed in are removed; only the kind of error, when it was first and last seen and how often it happened are kept.
Purpose: security, fraud prevention, and diagnosing technical issues.

2.8 Problem Reports and Support Cases

What a problem report contains. A member of a workspace's team can report a problem to Siraja from Help in the Service. A report holds the category chosen, the subject and description the person writes, which kind of screen it was about (the screen's general address, never which record was open), any request or incident ID entered, which app was used and its version, who reported it and when. Please leave passwords, codes and other people's personal details out of what you write. Residents using a tenant portal do not report problems through Help; anyone may ask for help from the public Support page (below).
The optional diagnostic attachment. Only if the person reporting ticks the box, which starts unticked, the report also carries a few facts about the browser, all listed beside the box before it is sent: the browser and its version, the device platform, the window size, the language setting, whether the device was online, and the IDs of up to five recent requests that failed. Nothing else: no passwords, records, messages or documents.
A support case. Each report becomes a support case. Siraja may also open a case for a workspace itself. A case keeps its status, the dates it changed, information the workspace adds later, Siraja's messages, and Siraja's internal notes.
Who can see a case. The team member who reported it, the people who manage the whole workspace (not those whose access is limited to some properties), and Siraja support. Other team members and residents cannot see it. The diagnostic attachment and Siraja's internal notes are seen by Siraja support only.
Siraja support's access to workspace data. A support case does not by itself give Siraja access to a workspace's records (its properties, residents, leases, money records, documents or messages). Siraja support may ask for access while a case is open, and gets it only if a person who manages the whole workspace approves, for a limited time of at most 8 hours, which the workspace can end at any time; it also ends when the case is resolved or closed. An approval is for one of two things: a read-only view of how the workspace is set up (its settings, its properties or only those the workspace allows, their spaces, and how many leases each has by status); or account help for a resident of the workspace, or someone invited to it, whose exact email address Siraja is given: whether they have a Siraja account, whether it is linked to the workspace, the state of their invitation and its email, and their sign-in status, and, with the same approval, resending an invitation or verification email, sending a password-reset email, or ending that person's sign-in sessions. For the workspace's own team members, under an open case, Siraja support may check the same sign-in facts, send a verification or password-reset email again, end their sign-in sessions or withdraw their unused recovery codes without a separate approval. Siraja support never sees passwords, codes, payments, documents or messages this way, never signs in as anyone, never sets a password, and never edits the workspace's properties, residents, leases or money records. Every use of an approval is shown to the workspace in Settings › Privacy; every action taken is recorded in the case and in the workspace's audit trail; and every check is recorded in Siraja's own access log.
Siraja's operations view. To run the Service, answer support, bill for Siraja's plans and keep the Service secure, Siraja's operations staff can see, without a workspace's approval:

- totals for the whole Service; - workspaces, by name and Siraja Account Number, where Siraja has to act on them: their Siraja subscriptions, payments and refunds, requests to close a workspace, complimentary workspaces, and advance notices of plan allowances; - a downloadable summary of every workspace: its name, Siraja Account Number, status, country, when it was created, how far it is set up, how many properties, spaces, rental positions, residents and team members it has, whether it is complimentary and its plan; - for a workspace found by its Siraja Account Number, an Incident ID or a support case: the same details, its Siraja plan and billing records, how many of its team are Owners, when its team last signed in, its support cases and any request to close it; - the name of the person who reported a support case or asked for a workspace to be closed; - a person's email address only when that person wrote to Siraja support from the public Support page, so that Siraja can reply.

They never see a list of people or of their contact details, and never a person's phone number. A workspace is looked up only by an exact number - its Siraja Account Number, a Support Case Number, an Incident ID or a receipt number - never by a name or an email address. A person's account is looked at only under an open support case, from the exact email address given for it or confirmed by that person in a request linked to the case. Each look is recorded in Siraja's own access log; it is not shown to the workspace in Settings › Privacy. This view never shows a workspace's records: residents' details, leases, money records, documents or messages.

Asking for help from the public Support page. Anyone - a resident, someone invited to a workspace, or someone who cannot sign in - may ask Siraja support for help with signing in or their account from the public Support page. A general support request holds the email address given, the category chosen, the subject and description written and any Siraja Account Number or Support Case Number typed. A general support request is confirmed by a link emailed to that address, and is read after confirmation. Complaints and legal notices follow Section 2.8A instead: they are recorded when received and do not wait for email confirmation. Only Siraja support reads a request. Siraja finds the workspace a request is about only by an exact number the person gave - a Siraja Account Number, an Incident ID or a Support Case Number - never by their email address, and checks no address against any workspace before a case exists. If Siraja opens a case with a workspace to help, the workspace's managers see Siraja's own description of it, not what the person wrote; Siraja looks at the person's account only under that case, by the rules above.
Notices after help with an account. When Siraja support ends a person's sessions, withdraws their recovery codes, or sends them a password-reset or confirmation link under a support case, Siraja emails that person at their own address to say what was done, when, and how to report it if they did not ask.
Notices Siraja must send. When the Billing Policy requires Siraja to tell a workspace's Owners something in advance, such as before plan allowances apply to it, Siraja emails the notice to each Owner's own address. Siraja's operations staff choose the workspaces and see whether each notice was delivered; they do not see the addresses.
Identifiers. Each workspace has a Siraja Account Number (SIR- followed by seven digits), and each support case a Support Case Number (SIR-C-, the year and six digits). Quote them when you contact us. They identify a workspace or a case; they are not passwords and give nobody access to anything.
Purpose: to investigate and fix problems, answer the workspace, help people back into their accounts, keep the Service secure, and keep a record of the help given.

2.8A Complaints and Legal Notices

What is collected. When someone makes a complaint or sends a notice from the public Support page or from Help: the kind chosen, the subject and description written, any Siraja Account Number or Support Case Number typed, and, from the Support page, the email address given so that Siraja can reply. Siraja gives each a ticket number and records the time it reached us.
Siraja's record of handling it. The ticket, its kind, the deadlines that apply, when it was acknowledged, whether it was assessed and the evidence kept, what was done and how it was closed, with the notes of the person who handled it. It is written in Siraja's own words and does not hold your email address, but those notes can mention other details, so they are treated as personal information and removed as Section 8 says.
Purpose: to reply, to meet the time limits the law sets for complaints and orders, and to keep evidence of what was done.

2.9 Documents and Files

Where Documents is enabled for a workspace: the file itself (a PDF, JPEG or PNG), its title and original file name, its category, the property, resident, lease, expense, maintenance request or inspection it is filed against, its size and type, a checksum of its content, who uploaded it and when, the outcome of the safety checks, and any report, hold, archiving or removal made against it.
A file can contain personal information about residents, guarantors, team members and vendors (for example names, addresses, rent amounts and signatures). What a file contains is decided by the person who uploads it; Section 6 says what must not be uploaded.
Purpose: to store, check and show the rental documents a workspace chooses to attach to its records, to control who can open them, and to keep them secure.

2.9.1 Marketplace, where enabled

An advertiser deliberately chooses the description, rent, fees, amenities, accommodation preferences, availability, location precision, contact details and selected processed photographs shown publicly. City, locality, state or region and country support destination searches and controlled city-name aliases. Owner confirmation of an area is a statement by that owner, not independent location, ownership or identity verification. A search need not use the seeker's current location; we do not require device-location permission to search for accommodation.

The default public location is the locality. An exact address or telephone number is public only if the advertiser deliberately selects it and confirms authority to share it. A separate private address grant is available to authorized Owners for one inquiry's renter. Siraja records its scope, version, recipient and share/revoke history. Only that renter and currently authorized Owners can read an active private share. Revocation, closure, blocking, an erasure request or loss of the required authority stops access through that share. The private grant is not copied into public listing content or the inquiry's advertised-terms snapshot. These controls cannot recall an address already viewed, copied or included in an ordinary message.

Private tenant records, documents and repair photographs are not copied into advertisements automatically. Original listing photographs remain private; selected processed derivatives can be public after scanning and image processing. An optional gallery lets authorized advertisers reuse building or shared-area photographs within the same property without storing duplicate uploads. Room photographs and shared-area photographs are labelled separately. Existing publication and inquiry references can keep a gallery photograph after it stops being offered for new selections. Image processing removes embedded camera metadata but cannot remove visible people, nameplates or other clues in the picture. Public material can be downloaded by other people, and removing it cannot recall their copies.

A signed-in seeker can send a plain-text inquiry. Siraja retains the advertisement's terms at submission and the inquiry conversation. The seeker and the originally authorized property-team recipients can read it only while their current access permits. A new team member does not automatically inherit old private conversations. Siraja also records blocks, closure, reports, notification preferences and erasure requests. A report allows a currently authorized Siraja operator to inspect the reported message, processed image or listing and record a moderation decision; it does not grant general access to that workspace's private messages or documents. This is a specific exception to the operations-view description above.

Marketplace notification preferences are separate from security mail. Blocking or withdrawing an advertisement does not immediately erase legitimate conversations. Requesting Marketplace erasure closes the person's inquiries and requests removal of eligible inquiry content under Section 8; it does not delete their Siraja sign-in account or a landlord's tenant, occupancy, lease or financial records. An inquiry creates no reservation, tenancy, resident-portal permission or payment obligation. An existing account accepts a resident invitation separately and explicitly, and its other tenancies and financial histories remain separate.

2.10 Cookies and Browser Storage

Siraja sets three cookies and keeps a small number of items in your browser's own storage. It uses no advertising, analytics or tracking cookies, scripts or pixels. The pages it serves may load only from Siraja's own address and, where Documents or listing photos are enabled, from the private storage address that receives the files you choose to upload.

Cookies (sent to Siraja with each request to it):

`rental_session` keeps you signed in. It holds a random value, of which Siraja keeps only a one-way hash; it is HttpOnly (scripts cannot read it), SameSite=Strict and, in production, Secure. It lasts about 12 hours at most, ends when you sign out, and the Service cannot work without it. Platform access has a shorter eight-hour session limit, a 15-minute idle limit and recent MFA checks for sensitive actions.
`rental_google_signup` exists only if signing up with Google is offered and you use it. It carries which versions of the Terms and this Privacy Policy you accepted, with a signature, across Google's redirect. It is HttpOnly, SameSite=Lax, sent to one address only, lasts 10 minutes and is cleared when the sign-in completes.
`__Host-siraja_google_browser` binds a Google sign-in or sign-up to the browser that began it, helping prevent someone from signing a different browser into their account. It contains a keyed proof of the sign-in state, no customer information. It is HttpOnly, Secure, SameSite=Lax, host-only, lasts 10 minutes and is cleared by the callback.

Items in your browser's storage (not cookies, and not sent to Siraja unless you act on them):

Needed to carry out something you started: the link of a team invitation you opened (kept up to 7 days, until it is used or ends); a resident invitation you opened, a subscription checkout you began (up to 24 hours), the names and references of uploads still being checked, a half-saved tenant record waiting to be retried, the workspace name you typed while setting up, and whether you dismissed a notice (each for that browser tab only).
Where Marketplace is enabled, an inquiry draft and an allowlisted return path stay in this tab for at most 30 minutes so you can sign in, review and explicitly send. They are cleared after sending or signing out; the draft is bound to the account that reviews it. A selected resident-record reference stays in this tab until you change it, sign out or close the tab; it does not transfer authority between tenancies.
Remembering a choice: the plan you chose on the Pricing page (2 hours; cleared when you sign out); what you typed in the sign-up form - your email address, name and workspace name, never the password - if you left it to read a policy (used for 30 minutes); which property you were viewing and the property list's filters (cleared when you sign out); and the colour scheme you picked (kept until you clear it).

Signing out clears the property you were viewing, the property list's filters, the plan you chose, half-saved tenant details and the names of uploads being checked. A subscription checkout you began stays in that browser tab, tied to your account and workspace, for up to 24 hours, so that signing back in can reopen the same checkout instead of starting a second one. You can clear everything in your browser's settings at any time; the Service still works and chooses its defaults again. The iOS app does not use cookies for its sign-in: it keeps its sign-in and an encrypted offline working set in the device's protected storage.

Other companies' cookies. Siraja's pages set none. If you choose to sign in with Google, or open a subscription checkout, you are sent to Google's or Razorpay's own page, which has its own cookies under its own policy. Address suggestions, where enabled, are requested from Google by Siraja's servers; your browser does not contact Google for them.

Because none of this is used for advertising, analytics or tracking, Siraja shows no cookie banner and offers no cookie consent control. If it ever adds a cookie or storage item for analytics or advertising, it will first change this section and ask for your choice.

Depending on the applicable law and the purpose, we process personal information based on:

Your consent, given at signup and, where applicable, at each point additional information is collected (e.g. adding a guarantor, employment details, or identity document);
Providing the Service you or your landlord requested, including performing our contract with a workspace customer;
Compliance with law; or
Security, fraud prevention, legal claims, and other purposes permitted by applicable law.

The DPDP Act and Rules use a phased commencement. The provisions about consent managers are scheduled to take effect on 13 November 2026, and most of the duties of data fiduciaries and the rights of data principals on 13 May 2027. Siraja is preparing for those requirements now; this policy does not imply that every provision is already in force. Until then, the Information Technology Act, 2000 and the rules made under it, including the Reasonable Security Practices and Procedures and Sensitive Personal Data or Information Rules, 2011, apply to Siraja, and we act under them now. PIPEDA or applicable provincial Canadian privacy law may apply now to Canadian commercial activity.

Consent for tenants entered into the Service by a landlord or property manager is generally obtained by that landlord as part of the tenancy relationship. Where you interact with the Service directly (e.g. a tenant portal), we obtain your consent directly.

You may withdraw consent at any time by contacting us or your landlord, subject to the effect withdrawal may have on the tenancy record and any legal retention obligations described in Section 8.

We do not sell personal information. We share it only in the following circumstances:

With your landlord or property manager, if you are a tenant — they are the primary user of your information for managing your tenancy.
Google, if you choose to sign in with Google or use enabled Google Places address/area assistance. Where that assistance is enabled, the entered lookup text and selected place reference are sent to Google through the Service; ordinary Siraja destination search does not itself require a Google lookup. Google processes this data under its own privacy policy.
Your landlord's own email provider, for sending you invitations, receipts, or notices — landlords may connect their own email account to send communications.
Siraja's email delivery provider. Siraja separately sends its own transactional email (account verification, password resets, notices about your account or workspace, and acknowledgements of complaints) through a dedicated email delivery provider, Resend, whose sending region for Siraja is the United States. The message, the recipient's address and Siraja's reference for it therefore pass through the United States.
Cloud infrastructure providers, who host our servers and databases, under contractual confidentiality and security obligations. DigitalOcean provides the servers and database, and, where Documents is enabled, the private object storage for uploaded files in Bangalore, India. Uploaded files are scanned for malware by software Siraja runs itself; no file is sent to a third-party scanning service. For Canadian workspaces, this involves processing outside Canada and the cross-border considerations described below.
Razorpay, our payment provider, if your workspace subscribes to a paid plan. Razorpay collects the payment details you give it and processes the payment under its own privacy policy; we share with it only what a subscription needs, such as the plan and Siraja's own reference numbers for your workspace and subscription.
As required by law, including in response to valid legal requests from courts or government authorities in India or Canada.
In a business transfer, such as a merger or acquisition, with notice to affected users where required by law.

Cross-Border Data Transfer

Our servers are located in India. Where personal information is transferred across borders (for example, for users or properties located in Canada), we use reasonable contractual, organizational, and technical measures appropriate to the information and comply with applicable transfer requirements as they take effect. Information processed in another country may be accessible to courts, law-enforcement, or regulatory authorities in that country under its laws.

5. Data Security

We apply reasonable technical and organizational safeguards appropriate to the sensitivity of the information, including:

Encryption of data in transit (HTTPS/TLS) and encryption of sensitive stored credentials
Role-based access controls, so only authorized users within an organization can access that organization's data
Database-level isolation between different landlords' organizations, enforced independently of the application code, so one organization cannot access another's data
Secure password storage (passwords are never stored in plain text)
Uploaded documents are held in private storage, are not available until they have passed safety checks, and are authorized again each time one is opened (Section 6)
Regular monitoring and automated alerting for service availability and data delivery
Siraja's own access is limited and recorded (see Section 2.8): its operations staff see totals, workspaces by name and Siraja Account Number where Siraja acts on them, and a workspace's details and billing records - never a list of people or their contact details, and never a workspace's records; Siraja support sees how a workspace is set up, or helps a resident or invitee with their account, only with the workspace's time-limited approval, shown to the workspace in Settings › Privacy; and help Siraja gives the workspace's own team members with signing in, under an open support case and without a separate approval, is recorded in the case and in the workspace's audit trail

No system is perfectly secure. If we become aware of a data breach involving your personal information that poses a real risk of significant harm, we will notify affected individuals and the relevant regulatory authority (the Data Protection Board of India, and/or the Office of the Privacy Commissioner of Canada, as applicable) within the timeframes required by law. Where the directions of the Indian Computer Emergency Response Team (CERT-In) apply to a cyber security incident we have noticed, we report it to CERT-In within six hours of noticing it. A person at Siraja decides whether an incident is reportable; an ordinary application error is not one.

6. Operational Rental Documents

Where Documents is enabled for your workspace, authorized members can store files against the records they belong to. Documents is an operational rental-document library. It is not an identity-verification (KYC) service, a backup service or a general file drive. Where Documents is not enabled for a workspace, or uploads are paused, the Service holds only a record that a document exists (its type, title and dates); that record does not mean a file has been stored. A resident can attach up to three photographs (JPEG or PNG, each at most 5 MiB) to a repair report in the resident portal, and these are stored and checked in the same way; residents cannot upload any other file.

What can be stored. Only these kinds of document, each against a property, a resident, a lease, an expense, a maintenance request or an inspection that accepts it: rental agreements, receipts and invoices, tenant notices, inspection reports, maintenance invoices, maintenance photographs, insurance and compliance certificates, warranties, and building rules. A file must be a PDF, JPEG or PNG and no larger than 25 MiB (26,214,400 bytes). A maintenance photograph must be a JPEG or PNG image.

What must not be uploaded. Identity evidence or identity numbers (for example Aadhaar, PAN, passports, driving licences or voter ID), bank statements, cheques or card details, passwords or one-time codes, medical records, credit or screening reports, property title deeds, and files unrelated to the rental. The upload form lists these and asks the person uploading to confirm that the file is needed to run the rental and contains none of them. That confirmation is a statement by the uploader; it is not a substitute for any notice, consent or other authority required from the person whose information appears in the file.

Checks before a file can be opened. A file is not available to anyone until Siraja has checked it. We confirm from its content, not its name, that it is a PDF, JPEG or PNG and that it ends where it should. We refuse files that conceal another format or carry web-page code, scripts, launch actions or attached files, and PDFs that are password-protected. We then scan it for malware with software Siraja runs itself. If a check fails, cannot be completed or times out, the file is not made available. These checks reduce risk; they cannot read what a picture or page shows, and they do not guarantee that every prohibited item or threat will be detected.

Photographs and PDFs. When a photograph is stored, its camera information (such as location, device identifiers, timestamps, thumbnails and comments) is removed, so the stored photograph can differ from the original. A PDF that passes the checks is stored as it was uploaded, including any information inside it.

Where files are held. Files are held in private storage provided by DigitalOcean in Bangalore, India. There is no public link to a file. For a workspace in Canada, its files are therefore stored and processed outside Canada (see "Cross-Border Data Transfer" in Section 4).

Who can open a file. Each time a file is requested, Siraja checks again that the person is an active member of the workspace with the permission needed, whose access covers the record's property, and that the document is not withheld or removed. The download link it then gives is private and short-lived: about two minutes, and never more than five. Removing a person's permission prevents new links being issued to them. A link that was already issued can still be used until it expires, and someone who legitimately downloaded a file may keep their copy outside Siraja.

Reports and holds. A member who sees a file that should not be there can report it, choosing a reason from a list (for example identity document, financial record, health information, password or secret, not rental related, or malware suspected). A report immediately withholds the file from download while a person authorized to manage documents reviews it; they can restore access after review or keep it withheld. Removal waits for the preservation period in Section 8 and any further hold. Releasing a report does not override a failed safety check. A legal hold on a document prevents it from being removed until the hold is released.

Archiving and removal. Archiving takes a document out of everyday lists and keeps it; it does not delete the file. Removing a document makes it unavailable and asks storage to delete every stored version of its file, including any versions and delete markers the storage keeps. If storage is unavailable when a document is removed, the deletion stays pending and is retried. A minimal record that the document existed and was removed, and the entries in the workspace's audit trail, remain. Removal does not erase copies already downloaded by other people, and does not by itself erase copies held in backups (see Section 8).

Temporary upload copies. A file is first received in a temporary area. Siraja's cleanup deletes that temporary copy once the file has been checked, or when the upload is cancelled, fails or expires, subject to the preservation described in Section 8. A temporary copy is not the stored document.

Operating limits. To protect the Service, an upload can be refused when a workspace holds 5 GiB of retained documents, when a person has completed 200 uploads in the last 24 hours (counted across every workspace they upload in), when a person already has ten uploads in progress, or for a period after repeated attempts to upload prohibited files. These safeguards are separate from subscription plan allowances and never remove or hide documents already stored. Siraja may change them.

Your responsibilities. A workspace customer must have a lawful reason and authority to upload personal information, limit it to what the rental operation needs, tell the individuals concerned how it is used, give team members only the access they need, and apply lawful retention periods. Siraja operates the storage, authorization and security controls described here.

7. Your Rights

Depending on your location, you have the right to:

Access the personal information we (or your landlord, through the Service) hold about you
Correct inaccurate information
Request deletion ("erasure") of your information, subject to legal, accounting, dispute-resolution, and other permitted retention requirements (see Section 8 and "Deleting your Siraja account", below)
Withdraw consent, as described in Section 3
Lodge a complaint with an applicable regulator, which may include the Data Protection Board of India as the relevant provisions take effect, the Office of the Privacy Commissioner of Canada, or an applicable provincial Canadian privacy regulator

To exercise these rights, contact us at support@siraja.in, or contact your landlord directly if the request concerns information they entered for managing your tenancy. If your request concerns a workspace, please quote its Siraja Account Number, and for a support case its Support Case Number; neither is proof of who you are. For ordinary privacy requests, we acknowledge receipt within 48 hours and aim to resolve it within one month, or within the period required by applicable law. Where the intermediary rules apply to a content complaint, acknowledgement is within 24 hours and resolution within seven days; specified removal complaints have a 36-hour resolution period and qualifying intimate-content or impersonation complaints a two-hour action period. Orders follow their applicable periods. Some laws permit an extension or require identity verification before a request is completed. You can make a request or a grievance from the Support page (choose "Complaint or legal notice"), from Help, or by email. Each is given a ticket number and a record of when it reached us, and our Grievance Officer is named on the Business details and complaints page.

Deleting Your Siraja Account

You can ask for your own Siraja sign-in account to be deleted. While signed in, open Help, choose Report a problem, and pick "Delete my Siraja account". That creates a support case with a Support Case Number, which you can follow. Siraja confirms the request with you, at your account's address, before anything is done.

What it does: it ends your sign-in and your membership of every workspace, ends your sessions, removes your password, authenticator, recovery codes, linked Google sign-in and personal preferences, gives up system emails still waiting for you and blanks the address and text of those already sent, and replaces your name and email address in Siraja's account records with a placeholder.

What it does not do: a separate, restricted registration record keeps your name, email address, telephone number if supplied, registration date and cancellation date for 180 elapsed days after cancellation, and longer only while a recorded legal obligation, investigation or active dispute requires preservation. It contains no password, authenticator secret, recovery code or sign-in token. It is purged in bounded daily batches after that period once no hold remains. It does not change what a workspace holds. Records a landlord or property manager made, and who made them, stay with that workspace; the record that policies were accepted, financial and subscription records, security events and the audit trail stay as Section 8 describes; and your support case itself is kept for the period in Section 8. Backups kept by our infrastructure provider age out on the provider's schedule (Section 8) and are not rewritten.

What can stop it: it cannot go ahead while you are the only Owner of a workspace that is still open (hand ownership to another Owner, or have the workspace closed, and then ask again), while you hold a Siraja platform role, or while a legal hold is in place on a workspace you belong to. Siraja tells you which applies. Deleting your sign-in account does not transfer ownership or close or delete a workspace. If you are its only Owner, arrange an ownership transfer or workspace closure before requesting account deletion.

Marketplace inquiries and privacy requests

A signed-in seeker can request Marketplace erasure from My inquiries. This closes their inquiry relationships and marks eligible content for retention-aware removal. They may also contact Support. Content is not removed merely because a request was submitted: recorded deadlines, applicable preservation obligations, open reports and current holds are checked first. Account deletion and landlord-controlled tenant records have separate procedures below. A blocked or closed relationship cannot use a private address share or continue ordinary replies.

If You Are a Tenant

Much of your information in the Service is entered and controlled by your landlord or property manager as part of your tenancy agreement, independent of Siraja. Requests to correct or delete tenancy records (e.g. lease history, payment history) may need to go through your landlord, particularly where records must be retained for legal, financial, or dispute-resolution purposes.

If your landlord or property manager anonymizes your record, or you ask them to under this Policy, the words you wrote in repair reports, requests, follow-ups, notes and conversations are replaced with the word "Removed", your photographs and other documents filed against you are removed unless a legal hold covers them or they are a rental agreement or money evidence that stays with your record, your portal access and document shares end, and the record of what was reported (its reference, dates, statuses and who answered) is kept so the property's history stays intact. It is refused while you have a lease or tenancy that has not ended, and while a legal hold covers you. Replies written by the property team stay with the workspace.

If you request account closure, we will explain what can be removed and what must or may be retained. Closing login access does not automatically erase tenancy and financial records held in a landlord's workspace where retention remains lawful and necessary.

8. Data Retention

We retain personal information for as long as necessary to:

Provide the Service to an active account,
Meet legal, tax, or accounting retention obligations (which may require retaining tenancy and financial records for several years after a tenancy ends, depending on applicable law), and
Resolve disputes or enforce our agreements.

Financial and tenancy records are generally retained even after a tenant moves out or an account is closed, to preserve an accurate historical record, unless deletion is legally required or requested and legally permissible.

Operational documents (Section 6) follow the workspace's applicable retention rules and legal holds. Siraja does not automatically expire or delete a stored document file merely because of its age; it stays until an authorized person removes it, or until a retention review that the workspace's authorized people approve archives or removes it, and a legal hold prevents removal. A prohibited-content rejection, a content report or a manager withholding a document starts a minimum preservation period of 180 elapsed days from that disabling event for the stored file and associated records. Closing or dismissing the report, restoring access, or an erasure request does not end that period. A later disabling can extend it, and a further legal hold can keep it longer. If received upload bytes still exist, they are retained separately in private storage before temporary cleanup; that copy is not offered for download. Private preservation metadata snapshots and that separate copy are removed in bounded housekeeping after the minimum period once no hold remains; the ordinary document then follows the workspace's removal process. Temporary upload copies are otherwise cleaned up separately and are not retention periods. Siraja's infrastructure provider keeps backups of Siraja's servers and databases: the database is backed up daily and each backup is kept for 7 days, and the server is backed up daily and each of those backups is kept for 7 days. A record deleted from the Service can therefore remain in a backup until that backup expires, up to 7 days later, and is not removed from it earlier. Stored files are not part of those backups; they are held in the provider's separate object storage, where removing a document asks storage to delete every stored version of it, and the provider's Data Processing Agreement permits isolated backup copies until automatic disposal without specifying a per-file physical deletion deadline. The backup periods above are the provider's current settings and can change. Siraja makes no promise about when a backup copy of removed information ceases to exist, and removing a document does not by itself remove it from backups. If a backup were ever restored, Siraja would apply again every deletion and anonymization recorded since it was made before the restored service is used.

Records of Siraja's own paid plans — subscriptions, payments, receipts, refund requests and refunds — are kept for as long as accounting and tax law requires, including after a subscription ends or a workspace closes. That duty is Siraja's own, for its books; it does not extend the period for which a workspace's tenancy and rental records are kept, which follows the workspace's own retention (this Section). System and security logs, which can hold IP addresses, request paths and times, are kept for the period needed to investigate incidents and to meet the legal requirements that apply to Siraja for such logs. The free-trial fingerprint of an email address is erased 24 months after the trial started; the record of which workspace and which account started the trial is kept, as is the record of each advance notice of plan allowances.

What residents send through the portal (Section 2.6A) follows the workspace's own retention rules and legal holds, like its other tenancy records. Siraja does not set a fixed period for it and does not delete it automatically because of its age. It is removed when the workspace removes it, or when the resident's record is anonymized as Section 7 describes. A photograph a resident sent stays while a legal hold covers it. The audit trail records who opened what and is kept as Section 8 describes for the audit trail.

Problem reports and support cases (Section 2.8) are kept for 24 months after the case is closed or resolved. Then their written and diagnostic content is removed: the subject, the description, the screen, the request and incident IDs, the app version, the diagnostic attachment, and the text of every message, note and added information in the case. We keep a case longer than 24 months only while it is needed for a legal obligation to preserve it, a security investigation, the prevention of fraud, or an active dispute. After the content is removed we keep the case record itself (its Support Case Number, workspace, category, statuses and dates) and the records of any access or help given, including the workspace's audit trail. Once sent, a report cannot be edited or withdrawn in the Service, by you or by Siraja; you can add information while the case is open. If you ask us to delete a report's content before the end of that period, we will tell you what we can do; the Service does not yet support removing it early. Closing a workspace does not remove its cases.

A Siraja Account Number is kept permanently and never given to another workspace, including after a workspace closes. Incident records (Section 2.7) are deleted after 90 days. Reports of the app failing in a browser (Section 2.7) lose their description, page address, request reference and the account signed in 90 days after they were first recorded; only the kind of error, when it was first and last seen and how often it happened are kept.

The written notes in Siraja's record of handling a complaint or notice (Section 2.8A) are removed 24 months after it is closed, unless a legal obligation to preserve it, a security investigation, the prevention of fraud or an active dispute requires them kept; the ticket, its dates, what was done and the outcome are kept, as the audit trail is. A record of a legal order, a government or agency request, or a cybersecurity incident is not removed automatically with an ordinary complaint's: it is held from the moment it is recorded until a person at Siraja has recorded a preservation review - the reason, who was responsible and the date it is next reviewed - and later records a release of the hold with its reason. Closing the matter is not that review, and a review date that passes does not release the hold. Once released, the ordinary 24 months apply; the reasoning for what was decided and done is kept with the dates.

General support requests made from the public Support page (Section 2.8) that are never confirmed are deleted after 7 days. A confirmed general support request's written content - the email address, subject, description and the numbers typed - is removed 24 months after Siraja closes it, answers it or links it to a support case, or 24 months after it was confirmed if none of these happens; longer only while it is needed for a legal obligation to preserve it, a security investigation, the prevention of fraud or an active dispute. Complaints and legal notices (Section 2.8A) are recorded when received and do not wait for email confirmation; their handling and retention follow the complaint and legal-preservation rules above. Removing or deleting a request also removes the address from the record of its confirmation email, where one exists.

Marketplace retention

For Marketplace, the following ordinary minimum periods apply before bounded cleanup can remove eligible content. A later recorded deadline, an open report, an applicable preservation period or a legal hold keeps it longer. Cleanup is asynchronous; these are eligibility rules, not promises of immediate physical deletion.

Inquiries: at least 30 elapsed days from creation, and only after the inquiry is closed. Open inquiries are not aged out. The later of the saved deadline and the current policy period applies, so extending the policy protects existing inquiries and shortening a policy does not shorten their saved deadlines. Eligible redaction removes the conversation's text/authors, advertised snapshot and private-address content and cached responses; structural references and audit history remain.
Listing content: at least 30 days after withdrawal for eligible withdrawn content. Superseded revisions can become eligible after 30 days from their creation. Current public/saved revisions and revisions needed by an unerased inquiry are protected.
Resolved reports: their eligible text and reporter identity can be removed after at least 30 days from resolution; open reports and applicable preservation duties prevent removal. Structural moderation and audit records remain.
Unreferenced listing photographs: eligible cleanup waits at least 7 days from the applicable removal or unreferenced-cleanup starting point, and rechecks current publication/inquiry references, processing state and holds before deleting stored objects. Withdrawing one listing does not remove an image needed by another protected reference.
Consumed notification records: eligible cleanup waits at least 7 days from consumption and checks any related inquiry preservation requirements. This does not recall a message already delivered to a recipient's mailbox.

The minimum ordinary periods above do not replace applicable duties to preserve reported/disabled content and associated records for investigation. Public removal and private evidence preservation are different actions. Account registration preservation after cancellation is described in Section 7. Object-provider versions or isolated backups can remain under the provider's disposal arrangements; database redaction alone is not proof of physical deletion from every stored copy.

Privacy decisions and recovery

Siraja records privacy, retention, preservation and access-restriction decisions needed to prevent an older restored backup from silently undoing those decisions. Where the independent recovery journal is used, restricted encrypted copies outside the database contain resource/account references, observation times, decision state, deadlines and applicable reason metadata. It does not store passwords or authenticator secrets or serve as a public conversation archive. Its purpose is security, accountable privacy handling and recovery, not advertising or profiling.

These recovery records and their protected key/checkpoint custody are kept while needed to reconcile retained backups or meet preservation duties. They are not automatically purged by Marketplace's ordinary content-cleanup schedule; removal requires a reviewed retention decision that accounts for outstanding backups and holds. Recovery must reconcile supported decisions and stop for unsupported or conflicting identity/file/provider cases before reopening affected access. A successful database restore does not itself establish that external files, cached copies or provider backups are safe to expose. Local same-device custody is not a guarantee against loss of the entire device or administrator access.

9. Children's Data

The Service is not directed at children. Nobody under 18 may create an account, sign in, sign a lease or accept our Terms, and we do not knowingly collect personal information from anyone under 18 ourselves.

A landlord or property manager who uses the Service, an adult, may record limited information about a child who lives at a property - for example, as a non-signing occupant of a household on a lease - because that is part of a tenancy record. That record is entered and controlled by the landlord or property manager, and Siraja stores it on their behalf. It can hold what any resident record holds: a name (the one required field), and, where the landlord or property manager chooses to enter them, a date of birth, contact and address details, an emergency contact, and the type and dates of an identity review. The Service refuses to make a person under 18 a signing tenant or a guarantor, and it does not accept identity documents or numbers. Siraja does not verify anyone's age and asks for no identity document for it. It uses one thing it already holds: where the date of birth a landlord or property manager recorded for a resident shows that the resident is under 18, the Service does not issue that resident a portal invitation and does not accept one issued earlier, so no account is created for them. Where no date of birth is recorded, nothing is inferred, and Siraja relies on the acceptance of the Terms. The occupant's record, and any account that already exists, are not changed by this. A landlord or property manager must have lawful authority to record a child's information, keep it to what the tenancy needs, and, where the law requires it, have a parent's or guardian's consent.

If you are a parent or guardian and believe a child's information was recorded without authority, or you want it corrected or removed, contact the landlord or property manager first, as the record is theirs to manage, or write to support@siraja.in and we will help route the request. If we learn that a child has been given an account, we will close it.

10. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be indicated by an updated "Last updated" date and, where required by law, we will notify you directly and/or request renewed consent. The version and date of the policy you accepted is recorded against your account.

11. Contact Us

For any privacy questions, requests, or complaints:

Email: support@siraja.in Place of business: Mohali, Punjab, India

See Business details and complaints for Siraja's principal place of business and Grievance Officer. You can make a complaint from the Support page or by email; the same recording and acknowledgement process applies to either route.

Our seller information, customer-care contacts and Grievance Officer are on the Business details and complaints page.