Run a client discovery workshop for a safer website architecture

Prepare an authorized conversation, not a security test

You need basic knowledge of websites, login, saved data and APIs. Work with a fictional client or someone who agrees to discuss their own project. This workshop does not authorize scanning, account access or changes to a live system. A paper diagram is enough to complete the exercise.

Begin with the client’s intended outcome: “Customers should save a room plan and return to it later.” Ask how staff currently handle that request. The NIST small-business guide offers a broader risk-management context; here you will produce a focused scope for one website workflow, not assess the whole company.

Ask questions that change the design

Use the first part of the conversation to understand actual work. Ask for examples rather than collecting a list of desired technologies. If a client says “we need a database,” ask which records must be saved and who should be able to change them.

1. What does a customer need to finish in one visit, and what must remain available later?
2. Which information belongs to one customer, and which is shared across the business?
3. Who may approve a price, refund, booking or stock change?
4. Which systems, exports and email threads hold copies today?
5. Who controls the domain, hosting and existing supplier accounts?
6. What would staff do if the website or a supplier were unavailable?
7. Which requirements are confirmed and which still need an owner’s decision?

Record unanswered questions explicitly. An assumption is useful only when the client can see it and knows what would change if it is wrong.

Map the fictional showroom before and after

In this original example, a showroom runs a website with local login accounts and a table of saved room preferences. Staff use a separate internal system for inventory and final quotes. Customers often send screenshots of a room plan by email because they cannot reliably return to a saved draft.

The proposed first release lets a signed-in customer save room dimensions and style choices. It does not promise a shared staff dashboard or automatic stock reservation. The internal inventory and price-approval process stay separate. A frontend, or the existing customer server, connects to the hosted API; the showroom does not install the Gammal Tech platform on its server.

Match requirements to documented functions

Gammal Tech documentation describes hosted login and one per-user, per-project JSON object up to 1 MB. Saved data is associated with the underlying account across sessions; the application receives a changing session token rather than a permanent identity record.

This can fit a small personal room plan after its data shape is checked. It does not establish that the showroom can list every customer’s plans in a central roster. Do not assume that feature or promise staff access that has not been documented.

Record compatibility questions for existing accounts, historical data, shared records and recovery. Keep unknowns as decisions to resolve, rather than filling the proposal with capabilities the client may later expect.

Give the remaining work a named owner

The client controls its own project and individual account. Do not ask for shared credentials or create duplicate personal accounts for testing. Use two consenting authorized people with their own verified accounts when a two-person test is needed. Any account transition must be agreed before the old login is removed.

Assign ownership of frontend code, dependencies, domain administration, hosting, staff devices and the business rules that remain. A compromised page could still intercept returned data or a session token. Domain registration does not make malicious code on the registered site safe.

For this exercise, exclude payments, AI and automatic owner notifications. If the client later requests them, revise the scope, permissions and usage budget separately. Do not present an expansion as free merely because basic login or storage has a free allowance.

Write a scope the client can actually accept

A concise scope should contain the following completed statements, using the showroom example as a starting point.

• Outcome: a customer saves a fictional room plan and retrieves it after signing in again.
• Included: interface, documented login integration, supported per-user data and an acceptance record.
• Excluded: shared inventory, automatic pricing, staff-wide customer listings and payments.
• Ownership: the client owns its accounts and project; maintenance responsibilities are named.
• Dependencies: verified account, registered HTTPS domain and agreed record structure.
• Acceptance: correct account retrieval, separate-user checks, clear failure handling and documented handover.

Plan verification early because onboarding can take around ten days. Migration preparation, testing and review remain real work even where the hosted function reduces future maintenance.

Assess your proposal and explain the benefit honestly

Give your scope one point for each question it answers: customer outcome, included functions, exclusions, data destinations, account ownership, remaining security work, testing, cost categories, unresolved decisions and handover. A missing answer becomes a revision task. This ten-point rubric evaluates clarity, not whether the client should buy the service.

Describe savings as a hypothesis to measure: selected local authentication and storage maintenance may be retired after a successful transition. Include integration effort, ongoing website security, support, usage and vendor review. Reduced staff effort might be redeployed rather than removed from payroll. Your deliverable is the scope, component table and open-question list, ready for client review before implementation.

Common questions

Should discovery include fixing the client’s live website?

Only when that work has been separately authorized and scoped. This exercise produces an agreed plan; it does not require access to real customer records or live changes.

What if the client wants cybersecurity for the whole business?

Identify that as a wider need. A website backend project does not replace assessment and protection of employee devices, email, networks, internal systems or incident-response arrangements.