Proof of Concept and Demonstrations Questions

Direct answer

A proof of concept (POC) is a time-boxed trial that shows the product works on the customer's own case, judged against success criteria (pass/fail results agreed in advance). I would treat the data-residency rule as the first design constraint, not an add-on. I would plan the three weeks around a small set of measurable objectives (three or four, each with a pass line), use synthetic or masked data wherever the core value can be proven without real EU personal data, keep every component that touches customer data inside an EU region, and produce evidence that nothing left the EU. The effort stays small by reusing the product as it ships, configuring rather than building, and proving a narrow slice end to end. If short of time in an interview, lead with: define what the residency rule covers, use synthetic data first, deploy EU-only, and produce evidence that nothing left the EU.

Step 0: agree what "never reach the US" means (day 1-2)

"Data stays in the EU" can mean different things, and each one changes the plan. I would ask the customer's security or data protection lead, in writing:

• Does it cover storage only, or also processing, backups, logs, metrics, error reports and support access?
• Is remote access by staff outside the EU (for example, a US support engineer viewing a screen) a breach, or only copies of the data?
• Is synthetic or masked data acceptable for week 1, with real data only in a later week?
• Who signs off on the data-handling set-up before real data moves (a data protection officer, the person responsible for privacy compliance, or the legal team)?

I would also check my own side: which components of our product run where (the product's control plane (the part that manages and configures the service, as opposed to the part that holds customer data), telemetry (usage and diagnostic data the product sends back to us), support tooling and any sub-processors, meaning third parties that handle data on our behalf), because these are the usual places data leaks without anyone intending it. I would confirm this per service from the documentation and the security team, not from assumption. A cloud provider's EU region does not on its own guarantee that no related service operates elsewhere.

Objectives (what the POC must prove)

I would agree a small set (four here), each with a pass line, written into a short success-criteria table (illustrative values):

High-level architecture

• A dedicated trial environment (a tenant, meaning one customer's isolated slice of a shared system, or a separate account) deployed in one EU region only, with no replication or backup to another region.
• Customer data enters through one controlled path (for example, a file upload or a connector to their test system). No copies on laptops.
• Logs, metrics and traces for this environment are stored in the same EU region. If our standard telemetry leaves the EU, it is switched off or scrubbed for this trial, and I say so in the plan.
• Outbound network access is restricted to an allow-list (a list of the only destinations permitted; everything else is blocked) of EU endpoints.
• Access is by named individuals, through the customer's single sign-on where possible, with access logging switched on.

Three-week plan

Keeping engineering effort low

• Use the product's standard deployment, no custom code. Configuration, one connector and sample scripts only.
• Generate synthetic data matching the customer's schema, so real data is needed only for the narrowest slice.
• Prove one vertical slice (one thin path through every layer, from input to visible result) well, for example one order file loaded, processed and reported on screen inside the EU region, rather than ten half-working features, and list what is out of scope in writing.
• Reuse existing test scripts and dashboards.

Data-handling steps and monitoring

1. Agree data classification (labelling data by sensitivity, such as personal or public) and sign the data processing terms (the contract, called a data processing agreement under GDPR, governing how a vendor handles personal data for a customer) before any real data moves.
2. Mask or tokenise (hide, or replace with substitute values) direct identifiers before upload if the use case allows.
3. Record every access. Review network flow records and endpoint logs weekly, and run a final check that lists all destination addresses contacted and shows each is EU-located.
4. At the end, delete the environment and the data, and give the customer written confirmation of deletion.

Variant: a two-week POC with single sign-on, 100,000 transactions a day, and a test and rollback plan

Interviewers often tighten the constraints to see what you cut. Here is how the plan changes if the same POC must fit in two weeks and also include these four items.

• Single sign-on: connect SAML (Security Assertion Markup Language, a standard for exchanging login assertions) to the customer's identity provider in week 1, with a test user and a test group, and verify a login, a logout and a removed-user case.
• Load: 100,000 transactions a day is 100,000 / 86,400 = about 1.16 transactions per second on average. Real traffic is bursty, so I would test at a higher peak, for example 10 per second (illustrative, to be agreed with the customer), for a full replayed day's volume, and report latency and error rate at each level.
• Test plan: functional run on day 3, load run on day 7, soak (steady load over a long period) on day 8, readout on day 10. Each has a pass/fail line in the criteria table.
• Rollback plan: because the POC runs in a separate environment, nothing in the customer's production changes. The rollback is to disable the connector or the single sign-on trust, revoke access, and delete the environment, with a written note of what was removed.

Trade-offs and pitfalls

• Real data makes the proof stronger but adds legal steps. Synthetic first is slower to impress but safer, and it keeps week 1 on schedule.
• Assuming "EU region" equals "never leaves the EU" without checking telemetry, support access and sub-processors.
• Scope creep: a three-week POC cannot prove everything. I would agree an explicit out-of-scope list.

Direct answer

I would separate the problem into three data tiers and use the lowest-risk tier that still convinces the buyer. Tier 1 is synthetic data (invented records with realistic shape and no real person behind them) for general demos. Tier 2 is a schema-and-statistics match: a synthetic dataset shaped like the prospect's data, built from aggregate profiles they approve, never their rows. Tier 3 is the prospect's real data, only inside an environment they control or under signed agreements, with masking (blanking or altering identifying fields), tight access and audit logs. Legal and security sign-off precedes any real personal data, and I am an architect, not their lawyer, so I confirm the rules with the prospect's compliance team and my own.

Terms in plain language

• PHI (protected health information): identifiable health data under the US HIPAA rules (Health Insurance Portability and Accountability Act). PII (personally identifiable information): data that identifies a person.

• De-identification: removing identity from data so it is no longer regulated as PHI. HIPAA recognises two routes, the Safe Harbor method (removing a defined list of 18 identifier types) and Expert Determination (a qualified statistician certifies low re-identification risk).

• Pseudonymization: replacing identifiers with tokens. The data is still personal data under privacy laws such as GDPR (the EU General Data Protection Regulation), because the tokens can be linked back with a key.

• BAA (business associate agreement): the contract under HIPAA that must exist before a vendor handles PHI for a customer. DPA (data processing agreement): the equivalent contract under GDPR.

• PCI DSS (Payment Card Industry Data Security Standard): the rules for handling payment card numbers. A demo should never contain real card numbers.

• Keyed hash (HMAC): a fingerprint of an ID computed with a secret key. The same ID and key always give the same token, so tables still join, but nobody can work backwards from the token to the ID without the key.

• Least-privilege access: each person gets only the access their task needs, and no more.

• Customer-managed encryption keys: the prospect, not the vendor, holds the keys that unlock the data, so removing the key makes the data unreadable.

The three tiers

Making synthetic and pseudonymized data real enough

This script generates 1,000 invented patient records with a distribution taken from an aggregate profile, and shows a keyed-hash pseudonym that stays stable across runs. It is illustrative; the key shown must never be in real code. What to take from it: the first function invents people whose age mix follows an approved aggregate profile (rng.choices(AGE_BANDS, WEIGHTS) draws one band at random with those probabilities), and the second shows a pseudonym: same input and same key give the same token every time, and the token cannot be reversed without the key.

import hashlib
import hmac
import random

rng = random.Random(7)
SECRET = b"demo-only-key"          # in real use: a managed key, never in code

AGE_BANDS = ["18-39", "40-64", "65+"]
WEIGHTS = [0.25, 0.45, 0.30]       # shape taken from a published, aggregate profile

def pseudonym(real_id):
    # keyed hash: stable token for joins, not reversible without the key
    return hmac.new(SECRET, real_id.encode(), hashlib.sha256).hexdigest()[:10]

def synthetic_patient(n):
    return {
        "patient_id": f"P{n:05d}",              # invented, no real person behind it
        "age_band": rng.choices(AGE_BANDS, WEIGHTS)[0],
        "visits_last_year": rng.randint(0, 12),
    }

rows = [synthetic_patient(n) for n in range(1, 1001)]
counts = {b: sum(r["age_band"] == b for r in rows) for b in AGE_BANDS}
print("rows:", len(rows))
print("age band counts:", counts)
print("pseudonym of 'MRN-48213':", pseudonym("MRN-48213"))
print("same input again:        ", pseudonym("MRN-48213"))

Output:

rows: 1000
age band counts: {'18-39': 291, '40-64': 418, '65+': 291}
pseudonym of 'MRN-48213': 847c7207e2
same input again:         847c7207e2

The sampled counts are 29.1/41.8/29.1 percent against the 25/45/30 target. That is a real miss on the 18-39 band, not rounding: with 1,000 draws the typical error (one standard deviation) for that band is about 14 rows, and 291 against an expected 250 is 41 rows off, roughly three standard deviations, so this seed is an unlucky draw (printed by the run above, not a typo). Random sampling matches a profile only on average. When the buyer will check the mix, assign by quota instead (exactly 250, 450 and 300 rows, then shuffle) or draw more rows. Fidelity comes from the distributions and relationships (visit counts per age, seasonal patterns), not from copying rows.

When a prospect wants their own data in the demo

1. Say the lower-risk option first: "I can reproduce the shape of your data with synthetic records built from your aggregate statistics, so you see the same behaviour without any real person's data leaving your control."
2. If they still want real data, run it in their environment. Deploy the demo into their cloud account or on-premises, so data never leaves their boundary. That is usually the cleanest answer to both "strict regulation" and "customer's real PII".
3. If it must run in my environment: put the contract first (DPA or BAA, plus the prospect's own security questionnaire). Then use an ephemeral environment (created for this demo and destroyed after), customer-managed encryption keys (they hold the keys, so revoking them makes the data unreadable) so they can revoke access, masking or pseudonymization of direct identifiers before load, named individuals only, least-privilege access (only what each person needs), and audit logging of every access. No copy to laptops, no use of the data for anything else, and a written deletion confirmation at the end.
4. Data minimisation: load only the columns and rows the demo needs, such as 5,000 rows, not the whole table.
5. Data residency: keep data in the country or region the prospect's rules require (for example, EU data stays in an EU cloud region).

Trade-offs and pitfalls

• "Anonymised" often is not. Combinations of age, postcode and dates can re-identify a person, so test claims of anonymity rather than assume them, and treat pseudonymized data as personal data.
• Public datasets are not automatically safe to demo: check their licences and that no real identifiers remain.
• A flashy demo on real data that fails a later security review costs the deal; a modest synthetic demo that passes costs nothing.
• What would change my call: a prospect with an air-gapped (disconnected) environment, or a regulator-mandated rule that data may not leave their premises, makes an on-site deployment the only option.

Direct answer

For a bank or a hospital system I make the compliance concerns part of the demo itself instead of an afterthought. I adapt the content to show the controls inside real workflows (who can do what, what is logged, where data lives), I run the demo in an isolated environment with synthetic data only, and I bring documentary evidence the buyer's risk and security teams can verify: reports, diagrams and data-handling commitments. I bring only evidence that exists and that I am allowed to share.

Adapting the content

I shift the order: lead with the business workflow, show the control at the moment it applies, and avoid a separate "security slide" that the technical staff must wait for.

Building the demo environment for a SOC 2-minded buyer who expects SSO

SOC 2 (Service Organization Control 2) is an audit report on a service provider's security and related controls; a Type II report covers how those controls operated over a period. A buyer who expects "SOC 2-like" controls will judge the demo environment by the same standard.

A short example of the audit entry I would show after a demo user approves a payment: 2025-06-10T14:03:22Z | user: j.rivera (role: approver) | action: approve_payment | object: PAY-10482 | source: SSO session | result: success. (The values are fictional.) The point is to show who, what, when and the origin, in a format an auditor recognises.

Evidence I bring (only what I actually have, and only what I am cleared to share)

• Our SOC 2 report, usually shared under a non-disclosure agreement, and the scope it covers. Another relevant certification (such as ISO/IEC 27001, an international standard for running an information security management programme) if we hold it. Which evidence comes first depends on the buyer: a bank's risk team usually asks first for the SOC 2 report, the penetration test summary and the data-flow diagram; a US hospital system usually asks first for the business associate agreement and how patient data is protected, then the SOC 2 report.
• A summary of the most recent independent penetration test, if the company shares one.
• An architecture and data-flow diagram showing where data is stored, processed and which sub-processors (third parties that handle data on our behalf) are involved.
• A data processing agreement template (the contract that sets how we handle personal data on the customer's behalf), and for a US hospital system, whether we sign a business associate agreement (the contract HIPAA, the US Health Insurance Portability and Accountability Act, requires with vendors that handle patient information). I confirm with legal rather than answer from memory.
• A completed security questionnaire or our standard answers.
• Our incident response and breach-notification process, described honestly.

Pitfalls

• Overclaiming ("we are fully compliant with everything"). Compliance is specific: which standard, which scope, which date. If I do not know, I say I will confirm.
• Using real customer or patient data in a demo to make it feel realistic. Never.
• A demo environment with relaxed settings that contradict what I say about production. If something is relaxed, I say so.
• Skipping the people who matter. The risk, compliance and security staff are the real audience, so I invite them to a dedicated session.

What would change my call

If the buyer needs proof I cannot give (a certification we do not hold), I say so and show the controls that exist today, and only facts that are true now (nothing described as planned or coming), instead of implying coverage. If the requirement is a hard blocker, I tell the account team early.

Direct answer

I would say yes to a 48-hour proof of concept (POC, a time-boxed experiment that tests whether the product works in the customer's setting) only for a narrow, written scope: single sign-on (SSO) for a handful of test users against a non-production test tenant (a separate, throwaway instance of their identity system, not the real one) of their identity provider (IdP, the system that holds user accounts and vouches for them, for example Okta or Microsoft Entra ID). I would ask them for a test tenant, a named admin, the IdP's metadata and a few synthetic users, I would never take a production password or secret in chat or email, and I would close with a readout (a short results meeting and report) that separates "proved" from "still to prove in production".

How I run the 48 hours

Worked test case, with fictional values: user ana@test-corp.example in group poc-admin logs in and must land in our product with the Admin role; ben@test-corp.example in poc-viewer must land as Viewer; cho@test-corp.example, in neither group, must be refused with an access-denied page. Scope I would write down: (1) a user from the test IdP logs in with SSO, (2) a user outside the allowed group is refused, (3) a group in the IdP maps to a role in our product. If they also want automatic user provisioning (SCIM, System for Cross-domain Identity Management), I would list it as out of scope unless the first three pass early.

What I need from them (five items)

1. A test or development IdP tenant with an admin who can register an application. Not production.
2. The IdP metadata: for SAML the metadata XML or URL (a file describing their login endpoint, signing certificate and entity ID), for OIDC the issuer (discovery) URL (an address that publishes the same details).
3. Two or three synthetic test users in two groups (for example poc-admin, poc-viewer), with MFA (multi-factor authentication) behaviour stated so I know what to expect.
4. The attributes they want sent (email, name, group) and which one is the unique user identifier.
5. A named contact reachable for the whole window, plus anyone who must approve a change on their side (for instance a security team).

I send them from my side: our SAML entity ID (the unique name our application goes by) and callback (assertion consumer service) URL (the address their system posts the signed login result back to), or the OIDC redirect URI (the same idea for OIDC), so they configure their end and I never need access to their admin console.

How I keep it safe

• Test tenant and synthetic users only. No real employee data, no production IdP.
• No credentials by email or chat. If an OIDC client secret must cross, it goes through a one-time secret link or their vault, is scoped to the test app, and is rotated or deleted at the end.
• Least privilege: their admin does the IdP changes while screen-sharing; I get no standing admin rights.
• Our side is a throwaway environment for this prospect, with a fixed expiry and teardown at hour 48 or when they say stop.
• Log what was done (who configured what, when) so the security reviewer can inspect it.

The directory (LDAP / Active Directory) variant

LDAP (Lightweight Directory Access Protocol) and Active Directory (AD, Microsoft's directory service) differ because the product usually needs a bind account (a service login to search the directory). My approach: do not ask for a real bind password. Options in order of preference: (a) a connector or agent running inside their network that they configure themselves, so the secret never leaves; (b) a read-only service account limited to a test organisational unit (OU, a folder-like container in the directory) with synthetic users, connected over LDAPS (LDAP over TLS), the secret shared as above; (c) if neither is possible in 48 hours, I stand up a sample directory (for example an OpenLDAP container with fake users and their real attribute naming) and prove the mapping logic there. Minimal configuration: server address, search base (where in the directory tree to look), user filter (which entries count as users), attribute map and group map. For example the customer enters server ldaps://ldap.test-corp.example:636, search base ou=poc-users,dc=test-corp,dc=example, user filter (mail={email}), and maps attribute memberOf to our roles. I would be explicit that (c) proves our logic but not their network path.

Presenting the limits

I would use three columns in the readout, spoken in plain words:

Example lines: "What you saw is a working login against your test tenant. It does not tell you how this behaves with your conditional-access rules or 8,000 real users, and I would not want you to read it that way. Here is the two-week path that does."

Trade-offs and pitfalls

• Saying yes to everything in 48 hours produces a half-proved demo that later reads as a failure. A smaller, fully passing scope beats a wide one.
• The usual delay is on their side (waiting for an admin), so I name the admin and a fallback before hour 0, and the clock starts when the test tenant is ready, not at the email.
• If a call is needed to unblock a stuck assertion, check clock skew, the audience/entity ID and the callback URL first, because mismatches in those three are among the most common causes of a failed first login in practice (an experience-based observation, not a measured share). Clock skew: login assertions are valid only for a few minutes, so a server clock that is 10 minutes off makes a fresh assertion look expired. Audience/entity ID: the assertion names who it is for; if their system says https://app.vendor.example/saml and we registered https://app.vendor.example/saml/, the trailing slash alone makes us reject it. Callback URL: if the IdP sends the user to a different address than the one we registered, it refuses or the browser lands on an error.

Direct answer

In the room I stay calm, thank the person, do not argue or reassure with something I cannot verify, ask exactly what they saw, and commit to a specific follow-up from our security team. In the next hour my team reproduces the issue and decides whether it is a real vulnerability (a genuine security weakness) or an artefact of the demo set-up (a side effect of how the demo account is configured that would not exist in the real product). Afterwards I send a short, factual written response and offer a session with our security people, so the customer sees a competent, honest process, which is often more persuasive than a flawless demo.

In the room (the next 2 to 3 minutes)

1. Acknowledge, do not defend. "Thank you for raising that. I want to understand exactly what you are seeing."
2. Get precise. "Which step, and what looks wrong to you? Is it the token in the URL, the data shown, the missing prompt?" Write it down, ideally with the screen still up so I can note the exact view.
3. Do not dismiss it with a guess. Never say "that is just demo data" or "that cannot happen" unless I know. If I do know it is a demo-only configuration, I say it carefully: "I believe that is how this demo account is set up, and I will confirm that with our security team and tell you."
4. Do not go deep on details of a possible real vulnerability in front of the room, and do not speculate how it could be exploited.
5. Commit to something concrete. "Our security team will look at this today. I will write to you by end of day tomorrow with what we found." Then continue with the rest of the demo, avoiding that flow, or ask whether they prefer to pause on it.

The next hour (internal)

If it is a real flaw, it follows the company's vulnerability handling process (the agreed steps for triaging, fixing and disclosing security flaws). I do not discuss exploit details (the exact steps someone could use to abuse the flaw) in broad email threads. If it is a demo artefact, I fix the demo environment so it does not come up again.

Worked classification: the reviewer says "I can open another user's record by changing the number in the address." Product security tries it. In the demo tenant both users share one seeded account, so the record is the same user's own (bucket b, demo artefact). Had it shown a different customer's record in a production-like environment, it would be bucket (a), a real flaw, and the serious-case path below applies.

What I send afterwards (within a day)

A short, factual note, copied to the AE and with security looped in:

Thank you for raising the [description] in yesterday's demo. We took it seriously and our product security team reviewed it the same day.
What we found: Worked example, for a customer who saw a session token (a login key) in the web address: "The demo account runs with a relaxed setting that puts the token in the address bar. That setting does not exist in production, where the token is sent in a protected header. Here is the production configuration page." Other possible outcomes: [one of: it was a demo-environment setting that does not exist in production, with the production behaviour described; or it is an issue we have confirmed and are addressing through our standard process, with an honest status; or it is intended behaviour, with an explanation of the control that applies].
What this means for you: [the customer-relevant point].
Next step: We would be glad to set up a call between our security team and yours to walk through this and answer anything else your reviewer needs. Here are our security documentation and the contact for your reviewer.

I do not claim "we have no vulnerabilities". I describe the process and the evidence.

Keeping the deal moving

• Offer a technical security session with their reviewer within the week.
• Share the documents they are likely to need next (security overview, architecture and data-flow diagram, a penetration test summary, meaning the report from a hired team that tries to break in to find weaknesses, if the company shares it under NDA, meaning a non-disclosure agreement).
• Keep other workstreams going (the proof-of-concept plan, commercial discussions), so the issue is one thread, not a standstill.
• Tell the AE early, so the commercial conversation is consistent with the technical one.

Pitfalls

• Getting defensive or minimising: this reads as dishonest even when you are right.
• Confirming or denying a vulnerability from memory in the room.
• Letting the follow-up slide. The customer is testing how you behave when something goes wrong.
• Promising a fix date I do not control.

What would change my call

If the issue is clearly serious (for example, access to another customer's data), I pause the demo, tell the customer a follow-up will come from our security lead, and escalate immediately instead of continuing the agenda.