What to ask a SaaS development agency about customer data access

You are choosing a SaaS development agency, and the next request is for your database, cloud account or a copy of production. If nobody owns the technical side yet, it is hard to tell which access helps the work and which access simply makes the contractor's day easier.

Source code ownership does not answer that question. A company can own its repository while customer records sit in a developer's laptop, a shared support login or an agent's conversation history. A technical founder can recognize those risks and still lack time to check each path.

Before granting access, get a written answer to five things: what customer data is needed, who or what can reach it, what they can do, where copies go and how access ends. Then ask for evidence in your own accounts.

The standard should match the task. Reviewing the codebase needs different permissions from investigating a failed import. Approving one should not silently approve the other, and a contract should not substitute for controls you can inspect.

Ask the SaaS development agency for a data access map

Start with a concrete request: “Show me every place customer information can be read, copied or changed during this work.” Include the application database, file storage, backups, support tools, error reports and any outside services receiving records.

For each place, the map should name the company account that owns it, the data involved, the person or service with access and the reason access exists. Mark whether it contains live customer information, generated test records or a deliberately reduced copy. Distinguish public product information from customer content, account identifiers and credentials, because those categories need different access decisions and handling.

Do not accept “we only need the repo” without checking what the repository contains. Configuration files, example exports and old commits can contain credentials or customer information. Logs and support attachments may expose more than the database permissions suggest.

Ask the proposed technical owner to walk through one real path, such as a customer uploading a file. Where does the file land? What gets extracted into logs? Which tools receive it? Does a developer download it to reproduce a bug?

The artifact you want is a short access register, not a polished architecture drawing. It should be specific enough that you can point to one entry and ask who approved it. Unknown paths belong on the register as unresolved items, with an owner responsible for investigating them before that access is granted.

Require a test-data path before production access

A SaaS development agency should explain how it can start work without unrestricted access to live customer records. Ask: “Which parts can you inspect with code, configuration metadata and generated test data, and what specifically would require production access?”

Synthetic data can support development and routine tests. A sanitized copy may reproduce a particular failure, but removing names does not necessarily remove identifying details from free text, filenames or unusual combinations of fields.

When live access is necessary, tie it to a named investigation. Record the records or storage locations involved, whether reading is enough, who approves the request and when access expires. Read-only access limits changes; it still allows someone to see or copy whatever the permission exposes. Record who can grant emergency access too, so an urgent failure does not become an undocumented exception nobody later removes.

Separate the ability to deploy code from permission to browse customer data where the stack supports that separation. Also ask whether deployed code can use a service credential to read records indirectly. A narrow personal login does little if the same person can trigger an unrestricted export.

For a non-engineer founder, the evidence can be a plain-language request attached to the work item and a walkthrough of the actual permission. For a technical founder, inspect the permission definition too. In both cases, broad access should have a documented reason rather than becoming the default because the team is small.

Make every human and service account attributable

Ask the SaaS development agency to name everyone who could reach customer information, including subcontractors and anyone providing emergency cover. “Our developers” is not enough to connect a later access event to a person. Include tools the contractor brings, not just accounts already visible in your own cloud environment.

Human access should normally use individual accounts, multifactor authentication and permissions limited to the task. Shared administrator logins make attribution harder and complicate removal when one person leaves. Keep the company's recovery methods under company control.

Service accounts need separate treatment. A deployment tool, support integration or coding agent may use a credential without a human signing in. Ask who owns each credential, where it is stored, what it permits and how it is replaced if exposed.

A secret manager can reduce casual copying, but it does not prove that credentials never leave it. Ask whether secrets appear in local files, terminal output, issue attachments or agent prompts. Those are different exposure paths with different cleanup work.

Agree who maintains the access register as people and tools change. The founder should not have to discover a new subcontractor through an unfamiliar login. Require approval before someone outside the agreed group receives access, and assign a technical owner to carry out that decision.

The evidence is simple: a current user list, the relevant service accounts and a demonstration that removing one user does not require sharing another person's credentials.

Separate agent permissions from model-provider data handling

If the SaaS development agency uses agentic engineering, ask what each agent can read and which actions need approval. Coding, test, security and documentation agents do different work; they do not all need access to production.

There are two boundaries to inspect. One is the agent's permission to use tools, such as searching a repository or running a database query. The other is the information sent to a model provider, retained in a session or written into execution logs.

Ask for the exact service, account and configuration used for your work. Then check its current terms for input retention, training use, available regional processing and access by subprocessors. An assurance about one account type may not apply to another.

Model instructions alone do not enforce a data boundary. The system should restrict which credentials and tools the agent receives. Customer text must not be able to grant access simply by containing instructions that an agent encounters. Ask whether a separate credential can limit one agent without changing access for the others.

Ask the named engineer to demonstrate a denied action using harmless test records. They should also explain how they review changes before release and how a failed or uncertain action reaches them.

Agents do the work. You make the decisions. The accountable engineer still owns technical review and execution. Your decision is which categories of customer information may enter which systems, with the tradeoffs documented before permission is given.

Test cross-customer access and support privileges separately

Have the SaaS development agency demonstrate that an account belonging to one customer cannot retrieve another customer's records. Use separate test customers and check actual requests, including file downloads, search results and background exports.

The OWASP authorization guidance recommends denying access by default and checking permission on every request. A hidden button does not establish that the underlying request is protected. Ask to see a negative test that attempts an unauthorized action and fails.

Support access needs its own demonstration. Can a support user impersonate a customer, reveal an attachment or export everything in an account? Which of those actions require approval, and where is the event recorded?

If staff can enter a customer's account to investigate a problem, define the permitted purpose and the limits. A support feature should not quietly become a standing route around the product's normal permissions.

Include automated jobs and integrations in the check. An export worker may run with broader permissions than the person requesting the export. The test should cover which customer's records the job actually reads and where the resulting file can be downloaded. Also test what happens after a customer's permission changes, including whether previously generated download links remain usable under the intended policy.

Keep the test results with the release evidence. Passing one demonstration does not prove every path is covered, but it gives you something concrete to repeat when permissions or product features change.

Keep customer data boundaries across marketing and sales

A SaaS development agency may also connect product activity to support, lifecycle messages or sales follow-up. Ask which fields leave the product and why. Developing the product should not imply permission to reuse its customer records elsewhere.

The systems that develop, market and sell the SaaS need explicit boundaries between them. A message workflow might need an email address and a specific event. It usually has no reason to receive the customer's uploaded documents or every field in their account.

Inspect one workflow from trigger to destination. Name the service receiving the information, the credential it uses, the fields sent and the copy retained after delivery. Include failed runs: retry queues and error messages can preserve payloads that the main workflow later deletes.

Treat exports as their own permission. A person allowed to inspect one support record should not automatically be able to download all customer records. Decide who can approve bulk exports and where an approved file may be stored.

Where agents prepare outbound or lifecycle content, define whether customer information can enter prompts and who approves sending. A founder approving a message needs enough context to decide without receiving a raw customer data dump. Approval of the workflow should cover its data use as well as its message content.

The useful artifact is a field-level example of the actual payload, with generated values, paired with the permission that allows the transfer.

Require evidence of access without copying the data

Ask the SaaS development agency to show what you could learn after an unexpected download or data change. The record should identify the person or service, the action, the affected scope and when it happened.

Logs should help explain access without reproducing the sensitive content. Recording a whole request body may create another store of customer information. Ask what is excluded, how long logs remain available and who can read or alter them.

Then walk through an access request from approval to expiry. Request a narrow permission using test records, perform the allowed action and remove the permission. Confirm that a new attempt fails. Check active sessions and stored credentials too; changing a user list may leave other routes open.

Assign someone to review unexpected access and own the response if customer information is exposed. Agree how they notify you, preserve useful evidence and stop further access. The founder needs a named technical owner rather than a promise that someone will notice.

Keep this demonstration repeatable. A short written procedure and a record of the result are more useful than a screenshot of settings that may change next week.

Put processing responsibilities in writing before access

Ask what the contract permits the provider to do with customer information, separately from who owns the code. The agreement should identify the work, the instructions governing data use, confidentiality responsibilities and the process for approving other service providers.

Where the GDPR applies and the provider processes personal data on your behalf, Article 28 sets requirements for the controller-processor arrangement. Whether that relationship applies depends on the actual processing. Have qualified counsel check the terms for your company, customer commitments and relevant jurisdictions.

The technical owner should supply the facts counsel needs: data categories, processing purposes, storage locations, onward transfers and deletion practices. A generic promise to comply with every law does not describe what happens to a customer attachment during debugging.

Ask for notice before a new subprocessor gains access and establish how you can raise an objection. Also separate the contract's incident-notification obligations from the operational contact who tells you something has gone wrong.

Compare written terms with the access map. If the map shows customer records passing through an external model provider, that path needs to be addressed in the processing terms rather than hidden under a broad reference to tools.

Signed terms need supporting evidence that the permissions match.

Account for copies, retention and restored backups

Ask the SaaS development agency what happens to customer information after a task ends. Include database copies, downloaded files, support attachments, logs, agent sessions and backups. Deleting the working database does not necessarily delete those other copies.

Separate revoking access from deleting data. Removing an account can stop future use while leaving an export on a device. Ending a tool subscription may not immediately remove retained records. Ask which copies can be deleted directly and which expire under a retention schedule.

Backups need a specific explanation. A provider may be unable to remove an individual record from a backup without replacing the backup. Document the retention period, access restrictions and what happens if an older backup is restored.

Restoration can bring previously deleted records back into the live environment. Ask how deletion requests are tracked and reapplied before restored data returns to normal use. Test the procedure with generated records rather than assuming the backup system handles it.

Distinguish customer content from evidence the company needs to retain for a legitimate purpose. The categories, reason and applicable requirements should be documented with appropriate legal input.

Request a written closure record for temporary datasets: what was created, where it lived, what was deleted and what remains until expiry. This gives the next technical owner an account of the remaining copies. Ask who confirms removal from contractor devices and third-party tools, and what evidence they can provide without overstating its certainty.

Make access evidence part of accepting the work

Before approving work from a SaaS development agency, attach the relevant access evidence to its definition of done. A feature that works in a demonstration may still introduce an undocumented export or a broad new service credential.

Use a small decision sheet to distinguish an answer from something you have checked:

Keep this decision sheet beside the work item rather than in a vendor's private workspace.

Record anything unverified as unverified. A confident explanation should not turn an unknown into an approval. If a task needs broad production access, you can narrow the task, add a review gate or postpone the work until the controls exist.

Check supplier removal before you depend on it. Our guide to checking a development company's exit terms covers the wider handoff; for customer data, the specific proof is that company-controlled administrators can revoke every agreed route without losing control of the product.

Acceptance can be small and explicit: the agreed change works, its data path is documented and the access used for the work has been reviewed. Keep unresolved risks visible for the next decision.

Frequently asked questions

Does a SaaS development agency need production data to start? Usually, code review and routine development can begin with narrower inputs. A specific production failure may justify limited live access, with a written purpose, approval and expiry.

Is read-only access safe enough? It prevents the changes covered by that permission, but it can still expose customer information. Check which records can be read, whether they can be exported and what other credentials the user can reach.

Can agents work without seeing customer records? Many coding and testing tasks can use source code and generated records. The real answer depends on the tools and credentials available to the agent, plus the information sent to its model provider.

Who owns approval if there is no first engineer yet? The founder approves business access boundaries. A named technical owner implements the permissions, explains the risks and supplies evidence. Legal questions may also need counsel.

Set one customer data boundary this week

Before giving a SaaS development agency its next task, take the next planned change in your own company and write its data boundary on one page. Name the customer information involved, the people and services that can reach it, the approval required and the point when temporary access ends.

If you already have a contractor, ask for a walkthrough using generated records. If you are still choosing a provider, use the same request in each conversation. Keep the result in a company-owned location so a future first hire can inspect it.

Choose one gap to close before the next data-touching task begins. That might mean replacing a shared login, removing a stale export or documenting which model provider receives agent inputs. Assign the work to a named owner and define the evidence you will accept. Give that owner a clear way to raise uncertainty before granting broader access.

Archer Scaling AI helps early-stage SaaS become AI-native. It builds and runs the systems that develop, market and sell the SaaS so the founder's time goes to the decisions. The AI-native assessment comes first, using read-only discovery across the company and codebase to produce a written report and plan.

For a conversation about your company, the codebase and who should own these boundaries, book a free intro call.