Privacy and security

How the private workspace handles information

Last updated: 30 September 2026. No Fries is operated from Auckland, New Zealand. This page covers the public managed IT website and assistant, verified service-scope access, customer dashboard signup and assessment use, and the private scoping, operator and service-desk workspaces.

Website assistant and prospect discovery

When you choose to message the No Fries website assistant, No Fries processes the conversation, a signed browser-session identifier, limited request and security metadata, and the business or contact details you provide. The signed browser cookie lasts for up to 30 days so the conversation can continue on the same browser. The assistant progressively stores structured facts, their source and known or unknown status, a rolling summary, suggested next action, and technical run metadata such as latency, model, token count and approximate cost. Simply loading the website does not create a prospect record; a record is created when a message is submitted.

The default structured preview uses deterministic application logic and is labelled as a preview. If the live model runtime is enabled, selected conversation context and the current message are sent from the No Fries backend to the OpenAI API to produce structured tool calls and a response. Model requests are configured not to store response objects in OpenAI. The OpenAI credential remains on the backend. Do not enter passwords, access tokens, recovery codes, payment data or raw security configuration; the application rejects common secret patterns before creating the conversation. High-confidence attempts to override, expose or bypass the assistant’s instructions are rejected before model processing and are not retained as prospect-conversation text by this security control.

Account setup and email verification

When you request a signup code, No Fries processes your chosen account type (Company or Consultant), the name you give your organisation or consultant workspace, your email address (personal or work), a private browser continuation, hashed verification data and limited security counters. The eight-digit code expires after 10 minutes and allows at most five attempts. The setup request is usable for 24 hours, including after verification. It does not itself create membership, accept terms, activate services or subscribe you to marketing. A business-looking email domain is not proof of organisation ownership.

When enabled, Resend delivers the requested code. Short-lived email-verification requests and security counters are stored in private Azure authentication storage and follow its expiry and lifecycle-cleanup policy. This cleanup does not apply to the durable representative and account records described below. The browser continuation is HttpOnly, Secure and limited to this site. The successful verification record removes the code hash; no code is placed in URLs, browser storage or application logs. Completing account activation requires the separate identity, organisation-authority and terms checks.

Representative records and account activation

After email verification, Company and Consultant signup asks for your full name, your role, the organisation or workspace's business address, an optional company registration number, and your explicit assertion that you are authorised to set up the dashboard and accept its terms. A consultant supplies these details and a separate authority assertion for each client organisation. No Fries retains these details with the verified email, account type, organisation name, verification and authority evidence, the offered schedule, and any actual terms acceptance and activation records to operate the account and document its agreed access.

These representative, account and client-setup records are stored durably in separate private Azure storage; accepted access and assessment records also use the dashboard database. They are not deleted when a verification code or its 24-hour request expires, or when the original 14-day starter period ends. There is no automatic deletion timer for these durable starter records, including unfinished setup. You can request access, correction or deletion using the contact details below; expiry alone is not account deletion. Recoverable storage versions and backups may remain for the configured infrastructure-retention period described below.

Email verification for the service scope

When you request the detailed managed IT scope, No Fries processes the email address you provide, a short-lived verification challenge, limited delivery and security metadata, and the time verification succeeds. The code and confirmation link expire after 15 minutes and can be used once. Verified browser access expires after 24 hours. The email is used to deliver and secure the requested scope and to record genuine interest; it does not by itself subscribe you to a marketing list.

Service-scope storage and providers

Verification challenges are stored in the application’s private Microsoft Azure storage, expire after 15 minutes and are deleted after successful use. Uncompleted challenge records follow the application storage-retention process. Only after successful confirmation, the verified email address and confirmation time are retained as an interest record. Resend is the intended transactional email provider for the verification message. Access cookies are signed, marked HttpOnly and Secure, and are not available to website JavaScript.

Website visitor tracking

The public managed IT overview does not load a third-party visitor-tracking script. Standard hosting and security logs may process limited request metadata such as IP address, time, requested path, browser type and response status to operate and protect the service. For a blocked instruction-manipulation attempt, the application records the signed session identifier, detector category and a one-way keyed identifier derived from the network address; it does not store the raw address or rejected message in that security-event record. The website assistant creates its signed session only when the assistant is opened or messaged, as described above.

Information processed

Approved users may enter customer profiles, discovery answers, notes, evidence references, internal qualification, service recommendations, proposal drafts, and CRM handoff metadata. When an operator confirms a lifecycle-to-scoping handoff, known prospect facts may pre-populate equivalent scoped answers or appear as context notes; unknown answers remain visibly unknown. Microsoft identity details are used to determine tenant and role access. Limited audit records identify who performed material actions and when.

Storage and location

The customer dashboard application and its PostgreSQL assessment database are hosted in Microsoft Azure New Zealand North. Dashboard authentication sessions, signup invitations, agreement archives and related access-control records use private Azure Storage in Australia East. Microsoft Entra ID provides identity authentication. Data is encrypted in transit using HTTPS and encrypted at rest by the applicable Azure service. Static application files do not contain a tenant service catalogue or customer records.

Tenant isolation and access

Microsoft sign-in is necessary but not sufficient. Backend checks restrict each request to an approved tenant and role. Tenant storage keys are derived server-side; browser requests cannot select a different tenant. Catalogue, customer, assessment, proposal, export, audit, and CRM routes require explicit capabilities.

Service catalogue and proprietary material

Uploaded service definitions and matching signals remain in authenticated tenant storage. They are not published in the public website or static JavaScript bundle. Authorised users can still see information required to perform their role, so contractual and organisational controls remain important.

CRM handoff

No Fries does not continuously read a CRM. The pilot integration is a user-initiated, one-way handoff of an approved proposal to a tenant-controlled endpoint. Endpoint details and credentials stay server-side. Production writes are disabled unless the operator explicitly enables them.

Retention, export, and deletion

The current default lifecycle policy makes raw prospect conversation messages eligible for removal after 90 days, abandoned unlinked prospect records eligible after 180 days, detailed AI observability events eligible after 365 days, and prospect security events eligible after 30 days. An authenticated administrator must preview the eligible records and explicitly run the retention job. Expired prospect security events are also pruned when a new security event is recorded. Linked scoping or customer records and conversations awaiting human contact are excluded from automatic selection. The structured lifecycle summary may remain after raw messages are removed where the prospect is still linked or active.

Authenticated operators can export an individual lifecycle record and its related conversation, audit, AI activity, and correction data as JSON. Administrators can delete an unlinked lifecycle prospect after typing its exact name, or delete a sales-workspace customer and associated assessments, proposals, and recorded handoffs. A linked lifecycle record cannot be deleted until its scoping customer is deleted or unlinked. Minimal audit metadata may record that retention or deletion occurred without retaining the deleted content. Platform backups or recoverable storage versions may remain for the operator’s configured infrastructure-retention period. Proposal exports are available only to authenticated users with export permission.

Do not upload

Do not enter passwords, API keys, private keys, authentication tokens, credentials, raw security configurations, or other secrets. During an evaluation, use fictional or specifically approved customer information and only service material approved for the external pilot environment.

Subprocessors and service providers

Microsoft Azure provides dashboard hosting, PostgreSQL and private storage in the locations described above, and Microsoft Entra ID provides identity authentication. Microsoft Entra B2B, through Microsoft Graph, sends customer-invitation messages when onboarding is enabled. Resend may provide transactional scope-verification email. The manual customer assessment and deterministic results do not require OpenAI; OpenAI processes assistant requests only when a separately identified live model feature is enabled, while the labelled deterministic preview does not call OpenAI. A tenant-approved Microsoft Power Automate or Logic Apps flow may be used for CRM handoff once configured. No public subscription billing is active.

Incidents and requests

For an access, correction, export, deletion, privacy, or security request, email hello@nofries.nz. Do not include secrets in the email.