Start with a bounded pre-bid data-protection question
Portfolio data protection for debt buyers starts with the question under evaluation, not a generic assurance. Before a pre-bid review, ask what each stage needs, who authorizes access, and where an introductory discussion ends. The aim is to judge whether a proposed workflow can be discussed without confusing ownership, purpose, or access expectations. This is a buyer-education framework, not a statement that Debt Catalyst presently implements a particular control or that any approach is legally sufficient.
A narrow opening question also helps prevent premature disclosure. A buyer can describe the intended review stage, the governance evidence it hopes to understand, or the scope of a future vendor evaluation. That is enough to begin assessing evaluation criteria. Consumer-level and account-level data do not belong in that exchange. Keeping the request limited lets the buyer assess how questions are handled before deciding, through its own stakeholders, whether a formal review is appropriate.
- Ask which pre-bid question can be addressed before detailed portfolio information is considered.
- Identify the buyer owner, review purpose, and approval point for later access discussions.
- Limit introductory requests to one high-level portfolio-level question; exclude consumer-level and account-level data.
Test owner and tenant isolation as a review boundary
Ask how a prospective platform defines the boundary between one client owner or tenant workspace and another. A useful response describes the criteria in business terms: who owns the review context, how authorized workspaces are distinguished, how permissions are intended to be scoped, and what evidence may support review of that boundary. A buyer need not request a public architectural blueprint. It needs a current explanation of the stated objective, approved public wording, and how exceptions or changes are handled.
The practical question is whether a proposed review is linked to the appropriate organization rather than treated as interchangeable across clients. Ask how a user is expected to see only materials relevant to that context, how a cross-boundary request is treated, and what record may show that work stayed in scope. An answer can identify limits, dependencies, or open items. That candor is more valuable than an absolute assurance that isolation eliminates risk.
- Ask how an owner or tenant boundary is defined for the proposed review.
- Request product-owner-approved evidence suitable for evaluating workspace and permission separation.
- Ask how exceptions, boundary changes, and out-of-scope requests are recognized and escalated.
Ask how support access stays exceptional and client-controlled
Support access merits separate pre-bid questions because a customer workspace is only part of the access story. Ask whether support access is described as beginning from a default-deny position, what event or approval would be needed before it could be considered, and whether the client retains meaningful choice. The objective is not sensitive technical detail. It is a clear process description: who may request access, who may approve it, what scope and duration are considered, and how activity may be reviewed afterward.
Evaluate client-controlled access as a governance expectation, not a marketing phrase. Ask whether the client can authorize, decline, limit, or revoke support access for its review, and what it is told when access is requested or changed. Ask how ordinary client-user access is distinguished from exceptional support activity. If a provider cannot make a current public statement, it should say so and route the question to the responsible product owner. Record the open question rather than turn uncertainty into an assurance.
- Ask whether support access begins with default-deny and a defined approval event.
- Ask what client-controlled choices exist to approve, limit, decline, or revoke access.
- Ask how support scope, duration, activity, and exceptions may be reviewed without implementation detail.
Review roles, multifactor authentication, and audit evidence together
Roles, multifactor authentication, and audit logging work best as connected evaluation topics. Ask how roles are intended to reflect job responsibilities, whether access is reviewed when responsibilities change, and how authentication expectations are described for the relevant users. Seek a current, product-owner-approved account of what may be stated publicly. A familiar control name does not establish a particular configuration or coverage level. These questions assess the quality of an access-governance discussion; they do not assert that a named measure is presently in place.
Logging questions should concentrate on accountability and reviewability. Ask which significant access or administrative events are intended to be auditable, who is expected to review available records, and what scope or limits apply. It is reasonable to ask whether log content is considered alongside data minimization without seeking sensitive examples. Distinguish an audit trail that may support review from a promise that every event will be detected or that risk disappears. The buyer can then identify needed evidence.
- Ask how roles and permissions are described, reviewed, and changed as responsibilities change.
- Ask what public statement is currently approved about multifactor-authentication expectations and scope.
- Ask which material access and administrative events are intended to be auditable, including limitations.
Confirm encryption questions and data-minimization expectations
Evaluate encryption through bounded questions rather than a checkbox. Ask whether the platform has product-owner-approved public wording about protecting information in transit and at rest, which information that wording is meant to cover, and whether exclusions or dependencies are disclosed. The goal is not to obtain architecture, key-management, or configuration detail. It is to determine whether the provider can give a precise, current account of the claims it is willing to make and can direct detailed diligence to an appropriate controlled process when needed.
Data minimization begins before access is granted. Ask what minimum high-level portfolio information is needed to frame a data-protection discussion, what is unnecessary at that stage, and how purpose limits, retention questions, or out-of-scope material are described. The buyer's own policies and agreements govern its decisions. For this draft-only access path, submit only a high-level portfolio-level question. Do not submit consumer-level or account-level data, files, identifiers, samples, or account examples through the form.
- Ask for approved public wording on information in transit and at rest, with scope.
- Ask which high-level portfolio facts are necessary for an initial data-protection discussion.
- Do not submit consumer-level or account-level data, files, identifiers, samples, or account examples.
Treat SOC 2 language as a status question, not proof
Evaluate SOC 2 wording as precisely as any other product-control statement. Before an independent attestation is issued, a platform should not call itself SOC 2 certified, SOC 2 compliant, or SOC 2 attested. Ask for the exact current wording approved by product ownership, when it was reviewed, and whether it distinguishes an internal objective, a planned assessment, or a completed independent attestation. Those are different facts. A questionnaire response or control objective does not become an attestation because it uses familiar terminology.
A limited answer can still be useful. It can state that an attestation has not been issued, avoid implying an unassessed scope, and identify the next step for controlled, current diligence information. Compare that answer with the buyer's own procurement, security, and legal review requirements. This draft does not decide what evidence is sufficient for a transaction, recommend individual handling steps, or promise that any control removes risk. It offers a pre-bid question set and preserves the distinction between verified status and aspiration.
- Ask whether an independent SOC 2 attestation has been issued and what scope is accurately described.
- Ask for wording that separates completed attestation from planned assessment, objective, or questionnaire response.
- Ask the responsible product owner to confirm every security and SOC 2 statement's currency.
Continue the decision path
Frequently asked questions
Direct answers for the specific decision this page addresses.
What security questions should debt buyers ask before sharing a portfolio?
Before sharing anything beyond a high-level portfolio-level question, debt buyers can ask how the provider describes owner or tenant isolation, default-deny support access, client-controlled access, role-based access, multifactor authentication, audit logging, encryption, data minimization, and the current status of any SOC 2 work. Ask which statements are product-owner approved, what scope and limitations apply, and how exceptions are handled. Do not submit consumer-level or account-level data through an introductory access request. The buyer should use its own procurement, security, legal, and compliance review to determine what evidence is appropriate.
How should a platform describe its SOC 2 status before an attestation is issued?
Before an attestation is issued, a platform should say so plainly and avoid describing itself as SOC 2 certified, compliant, or attested. It can direct buyers to current, product-owner-approved information about the security program and the scope of any future assessment. A planned assessment, security questionnaire response, or internal control description is not the same as an issued independent attestation. Buyers should ask which statements are verified for public use and when their status was last reviewed.