TL;DR

When evaluating implementation software like GoLiveFlow, security and SOC 2 questions come up fast, especially during procurement. This glossary defines every term you’ll encounter in vendor security reviews, from SOC 2 report types to encryption standards to access controls. It also addresses the common scenario of evaluating a vendor whose SOC 2 audit is in progress, with specific questions to ask and interim evidence to request. GoLiveFlow currently encrypts data at rest and in transit, supports SSO/SAML on its Enterprise plan, and offers role-based access controls while its SOC 2 certification is underway.

Why This Glossary Exists

If you’re evaluating an implementation platform, your security or procurement team will eventually hand you a vendor assessment checklist. Maybe they already have. The terms on that checklist can feel opaque, especially if your background is in project management or customer success rather than information security.

This glossary covers the security and SOC 2 questions that matter most when choosing software for customer onboarding and implementation workflows. Each entry includes a plain-language definition and a note on why it matters specifically for platforms that handle client portal access, e-signature approvals, project data, and cross-team collaboration.

Whether you’re filling out a vendor security questionnaire for the first time or reviewing a SOC 2 report from a potential implementation tool, this page gives you the vocabulary and the practical context to make confident decisions. For a broader look at how GoLiveFlow handles implementation workflows, explore the platform overview.

SOC 2: Core Terms

These are the foundational terms you’ll encounter in almost every GoLiveFlow security and SOC 2 conversation.

SOC 2 (System and Organization Controls 2)

A framework developed by the American Institute of Certified Public Accountants (AICPA) for evaluating how organizations manage customer data. It assesses controls across five categories called Trust Services Criteria. SOC 2 is not a law like HIPAA or GDPR. It’s a voluntary compliance standard and auditing procedure. But “voluntary” is misleading, because over 60% of businesses prefer to partner with SOC 2-compliant vendors, and roughly a third of organizations have lost deals specifically because they lacked the certification.

Why it matters for implementation software: Implementation platforms store sensitive project data, client contact information, approval records, and sometimes financial details. A SOC 2 report gives your security team confidence that the vendor has real controls around that data, not just marketing claims.

SOC 2 Type 1 vs. Type 2

A Type 1 audit evaluates whether security controls are properly designed at a single point in time. Think of it as a snapshot. A Type 2 audit goes further, assessing whether those controls actually work effectively over a sustained period, typically three to twelve months. Customers almost always prefer (and frequently require) a Type 2 report because it proves the controls aren’t just on paper.

Why it matters for implementation software: Your onboarding projects run for weeks or months. You need to know a vendor’s controls hold up over time, not just on audit day. If a vendor can only produce a Type 1, ask about their Type 2 timeline.

Trust Services Criteria (TSC)

The five pillars that a SOC 2 audit can evaluate:

Security (mandatory for all SOC 2 reports): Protection against unauthorized access, disclosure, and damage.
Availability: The system is operational and accessible as committed.
Processing Integrity: System processing is complete, valid, accurate, and timely.
Confidentiality: Information designated as confidential is protected.
Privacy: Personal information is collected, used, retained, and disclosed in conformity with commitments.

Only security is required. The rest are optional, added based on business needs. The most common combination for SaaS companies is Security + Availability. B2B platforms handling sensitive business data often add Confidentiality as well.

Why it matters for implementation software: If your implementation platform handles client-facing portals where customers upload documents and sign approvals, you probably want Availability and Confidentiality in scope alongside Security. When reviewing a vendor’s SOC 2, check which criteria were actually audited.

SOC 2 Report

A SOC 2 report is not a pass/fail certificate. It’s a detailed document from an independent auditor describing the vendor’s controls, any exceptions or deficiencies found, and the auditor’s opinion. The report includes a system description, management assertions, the auditor’s testing results, and (critically) the scope of what was examined.

Why it matters for implementation software: The SANS Institute emphasizes that Section 3 of a SOC 2 report outlines the actual scope of the examination. A vendor might have earned a SOC 2, but not on the product or service you plan to use. Always verify that the audited system is the one your team will rely on for onboarding projects.

Unqualified vs. Qualified Opinion

An unqualified opinion means the auditor found no material issues. It’s the clean bill of health. A qualified opinion means the auditor identified exceptions or deficiencies that prevent a fully clean opinion. A qualified opinion doesn’t automatically disqualify a vendor, but it means you need to read the details carefully and understand what went wrong.

Why it matters for implementation software: If your vendor’s SOC 2 report has a qualified opinion, look at whether the exceptions relate to controls that affect your data, such as access management for client portals or encryption of stored documents.

SOC 2 “In Progress”

This means the vendor has committed to obtaining SOC 2 certification and is actively working through the audit process, but the final report isn’t available yet. This is common for newer SaaS tools that are growing into enterprise readiness. GoLiveFlow’s SOC 2 status is currently in progress.

Being transparent about this is more trustworthy than dodging the question. Practitioners on Reddit’s r/cybersecurity forums note that many smaller vendors legitimately won’t have SOC 2 reports yet, and the real red flag isn’t the absence of a report but the inability to provide any evidence of security measures. One commenter put it simply: if a vendor can’t produce anything, not a questionnaire response, not a certification, not even a timeline, that’s when you walk away.

What to ask a vendor whose SOC 2 is in progress:

What is the expected completion date for the Type 2 report?
Can you provide a completed security questionnaire or a signed engagement letter with your CPA firm?
What controls are already in place (encryption, SSO, RBAC, audit logging)?
Will you contractually commit to a completion date?

Why it matters for implementation software: Many implementation platforms are category-defining tools built by newer companies. Ruling out every vendor without a completed SOC 2 would eliminate strong options. The better approach is to evaluate what interim controls exist and whether the vendor is demonstrably on the path to certification. You can contact GoLiveFlow directly to request current security documentation or ask about SOC 2 progress.

Vendor Security Assessment Terms

When your procurement team sends a security questionnaire to an implementation vendor, these are the terms that shape the conversation.

Vendor Security Questionnaire (VSQ)

A standardized set of questions sent to a vendor to evaluate their security posture. Topics typically cover data handling, access controls, incident response, encryption, and compliance certifications. Despite their importance, only 42% of organizations conduct comprehensive security questionnaires during vendor onboarding, even though 74% of data breaches involve third-party vendors.

Why it matters for implementation software: Implementation platforms sit at the intersection of your internal team and your customers. They handle project timelines, approval workflows, client communications, and sometimes payment data. A thorough security questionnaire is not optional for this category.

Security Questionnaire Frameworks

Three common standardized formats:

SIG (Standardized Information Gathering): A comprehensive questionnaire from Shared Assessments, widely used in financial services and healthcare.
CAIQ (Consensus Assessments Initiative Questionnaire): Published by the Cloud Security Alliance, focused specifically on cloud service providers.
VSA (Vendor Security Alliance questionnaire): An open-source questionnaire designed to reduce duplication across vendor assessments.

Why it matters for implementation software: If your vendor can respond to a recognized framework rather than just ad-hoc questions, it signals maturity in their security program. Ask which frameworks they’ve previously completed.

Bridge Letter (Gap Letter)

A management-issued document that covers the period between the end of a vendor’s last SOC 2 report and the current date. Bridge letters typically cover three months or less and confirm that no material changes have occurred to the vendor’s controls. They are not auditor-issued and not a substitute for a current SOC 2 report.

Why it matters for implementation software: If you’re midway through procurement and the vendor’s SOC 2 report expired two months ago, a bridge letter provides interim assurance. But if the gap exceeds three months, push for an updated report or a clear timeline for the next audit period.

Complementary User Entity Controls (CUECs)

Controls that the vendor expects you, the customer, to implement on your side for the overall security model to work. Common CUECs include configuring multi-factor authentication for your users, disabling accounts for former employees promptly, maintaining endpoint protection on devices accessing the service, and regularly reviewing user permissions.

Why it matters for implementation software: Implementation platforms give both your internal team and external clients access to the same system. If you don’t disable a former client contact’s portal access or fail to enforce MFA for your project managers, even a perfectly secured vendor can’t protect you. When reviewing a SOC 2 report, the CUECs section tells you exactly what responsibilities fall on your shoulders.

Subservice Organization Controls

Controls managed by the vendor’s own vendors. For example, if an implementation platform runs on AWS or Google Cloud, those cloud providers are subservice organizations. The SOC 2 report should describe how the vendor relies on these subservice organizations and what controls are “carved out” (excluded from the audit) versus “inclusive” (tested as part of the audit).

Why it matters for implementation software: Your data doesn’t just live on the vendor’s servers. It lives on their cloud provider’s infrastructure. Understanding who the subservice organizations are, and whether their controls were tested, gives you the full picture.

Compensating Controls

Alternative controls put in place when a primary control isn’t feasible. For example, if a system can’t support MFA natively, a compensating control might be IP whitelisting combined with enhanced monitoring.

Why it matters for implementation software: When a vendor’s SOC 2 is in progress or certain controls aren’t yet implemented, compensating controls show they’re managing risk through other means rather than ignoring it.

Data Security and Encryption Terms

These terms show up on every security questionnaire and are non-negotiable for any platform handling customer data.

Encryption at Rest

Protecting stored data by converting it into an unreadable format that requires a decryption key to access. The industry standard is AES-256 (Advanced Encryption Standard with 256-bit keys). GoLiveFlow encrypts data at rest.

Why it matters for implementation software: Your onboarding projects contain client documents, signed approvals, project plans, and potentially sensitive business information. If someone gains unauthorized access to the database, encryption at rest ensures they can’t read the data.

Encryption in Transit

Protecting data as it moves between systems, for example between a user’s browser and the application server, or between the application and a third-party integration. The standard is TLS 1.2 or higher (Transport Layer Security). GoLiveFlow encrypts data in transit.

Why it matters for implementation software: When a client logs into their onboarding portal, uploads a document, or signs an approval, that data travels across the internet. Encryption in transit prevents interception. If you’re building an onboarding playbook with conditional workflows, every interaction between your client and the platform should be encrypted in transit.

Data Residency

Where data is physically stored, meaning the geographic region of the data centers hosting it. This matters for compliance with regulations like GDPR (which restricts transfers of EU personal data) and for organizations with internal policies about data location.

Why it matters for implementation software: If your onboarding projects involve clients in the EU or other regulated regions, you need to know where the implementation platform stores their data. Ask specifically about data center locations.

Data Retention and Disposal

Policies governing how long data is kept after a project ends and how it’s permanently destroyed when no longer needed. Good policies define retention periods by data type and include secure deletion methods.

Why it matters for implementation software: After an onboarding project reaches go-live, what happens to the client’s data, documents, and communication history? Clear retention and disposal policies prevent unnecessary data accumulation and reduce breach surface area.

Access Control and Authentication Terms

Access controls determine who can see and do what inside a platform. For implementation software, where both internal teams and external clients share the same system, this section is especially critical.

SSO (Single Sign-On)

A mechanism that allows users to log into multiple applications with a single set of credentials, managed by a central identity provider (like Okta, Azure AD, or Google Workspace). SSO reduces password sprawl and gives IT teams centralized control over who has access.

GoLiveFlow supports SSO on its Enterprise plan ($99/month per seat). You can compare plans and SSO availability on the pricing page.

Why it matters for implementation software: When your team manages dozens of client onboarding projects, the last thing you want is separate login credentials for every tool. SSO also makes it easy to revoke access immediately when someone leaves the team.

SAML (Security Assertion Markup Language)

The protocol that makes SSO work between your identity provider and a service provider like an implementation platform. SAML passes authentication data securely so the user doesn’t need to enter credentials again.

Why it matters for implementation software: If your organization requires SAML-based SSO (most enterprises do), confirm that the implementation platform supports it and on which pricing tier. GoLiveFlow offers SAML on its Enterprise plan.

MFA (Multi-Factor Authentication)

Requires users to provide two or more verification factors to access an account. Typically this means something you know (password) plus something you have (phone, hardware key). MFA is considered a baseline security control.

Why it matters for implementation software: MFA protects against compromised passwords, which is the most common attack vector. Remember that CUECs often require your organization to configure MFA for your users. The vendor provides the capability; you must enforce it.

Role-Based Access Control (RBAC)

Permissions assigned by role rather than by individual. Instead of configuring access for each person, you define what a “Project Manager,” “Client Contact,” or “Executive Viewer” can see and do, then assign people to those roles.

GoLiveFlow includes role-based access controls across its plans.

Why it matters for implementation software: This is one of the most important controls for platforms where internal teams and external clients share the same system. You need your client to see their project portal but not your internal notes, capacity plans, or other clients’ data. RBAC makes that separation systematic rather than manual. When you’re trying to onboard customers faster, well-configured roles prevent access mistakes that could slow things down or create compliance issues.

Audit Trail

A timestamped, immutable log of actions taken within a system: who did what, when, and from where. Good audit trails capture login events, data changes, approvals, and configuration modifications.

Why it matters for implementation software: E-signature approvals, phase gate sign-offs, and task completions all need a clear record. If a client disputes that they approved a scope change, the audit trail settles it. For regulated industries, audit trails aren’t just nice to have; they’re required.

Compliance and Governance Terms

These broader compliance frameworks often come up alongside SOC 2 questions during vendor evaluations.

ISO 27001

An international standard for information security management systems (ISMS), published by the International Organization for Standardization. Where SOC 2 focuses on evaluating specific controls through an audit report, ISO 27001 certifies that an organization has implemented a comprehensive security management framework. Many vendors pursue both.

Why it matters for implementation software: Some enterprise buyers, especially in Europe and in regulated industries, require ISO 27001 alongside or instead of SOC 2. Ask your vendor whether it’s on their roadmap.

GDPR (General Data Protection Regulation)

The EU regulation governing the collection, processing, storage, and transfer of personal data belonging to EU residents. It applies regardless of where the vendor is based, as long as EU data subjects are involved.

Why it matters for implementation software: If any of your onboarding projects involve EU-based clients or end users, the implementation platform must handle their data in compliance with GDPR. This includes data residency considerations, the right to erasure, and lawful data processing.

HIPAA (Health Insurance Portability and Accountability Act)

The US regulation protecting personal health information (PHI). If an implementation platform processes, stores, or transmits PHI, it must comply with HIPAA requirements, which include specific encryption, access control, and audit logging standards.

Why it matters for implementation software: Healthcare SaaS companies using an implementation platform to onboard clinics or hospital systems may need the platform to be HIPAA-compliant. If this applies to you, ask whether the vendor will sign a Business Associate Agreement (BAA).

Third-Party Risk Management (TPRM)

The discipline of identifying, evaluating, and monitoring security risks introduced by vendors and partners. SOC 2 reports, security questionnaires, and ongoing monitoring are all core TPRM activities. Third-party vendors now account for more than 60% of enterprise cyber risk, making TPRM a board-level concern for many organizations.

Why it matters for implementation software: Your implementation platform is a third-party vendor. Understanding TPRM means understanding the process your security team uses to evaluate tools like GoLiveFlow, and knowing how to provide the right evidence to satisfy their requirements.

Questions to Ask Your Implementation Platform Vendor About Security

Armed with the glossary above, here are the specific GoLiveFlow security and SOC 2 questions (or questions for any implementation platform) that your procurement and security teams should be asking:

Do you have a current SOC 2 Type 2 report? If the audit is in progress, what is the expected completion date? Can you provide a signed engagement letter with your CPA firm?
Which Trust Services Criteria are in scope? Security alone, or Security + Availability + Confidentiality?
Is data encrypted at rest and in transit? What specific standards (AES-256, TLS 1.2+)?
Do you support SSO and SAML? On which plans, and with which identity providers?
What role-based access controls exist for client-facing portals versus internal teams? Can we configure custom roles?
What are the Complementary User Entity Controls (CUECs) we’d need to implement? Provide these in writing before contract signing.
How are e-signature records and approval audit trails maintained? What’s the retention period, and can we export them?
Who are your subservice organizations? Which cloud providers host our data, and are their controls included in your SOC 2 scope?
What is your data residency? In which regions are data centers located?
If your SOC 2 is in progress, can you complete a standardized security questionnaire (SIG, CAIQ, or equivalent)? What compensating controls are in place today?

These questions map directly to the glossary terms above. Print them, share them with your security team, and use them as a framework for any implementation platform evaluation.

How GoLiveFlow Approaches Security

GoLiveFlow’s current security posture, based on publicly available information from the platform:

Encryption: Data is encrypted at rest and in transit.
SSO/SAML: Available on the Enterprise plan ($99/month per seat).
Role-based access controls: Included across plans, supporting separation between internal team views and client-facing portal access.
SOC 2 status: In progress. GoLiveFlow is actively working toward SOC 2 certification.
White-label capability: The Enterprise/Partner tier supports reseller models with branded client portals.

This is a platform built specifically for SaaS implementation workflows, not a generic project management tool adapted for client onboarding. That specialization shows up in features like engagement scoring, AI risk detection, and built-in e-signature approvals with audit trails. See the full platform and security details here.

If your security team needs to complete a vendor assessment, reach out to GoLiveFlow directly to request security documentation, questionnaire responses, or an update on SOC 2 certification timing.

Frequently Asked Questions

Is SOC 2 a legal requirement for SaaS vendors?

No. SOC 2 is a voluntary compliance standard, not a law. But it has become effectively required for selling to enterprise customers. Industry data shows that about a third of organizations have lost deals because they lacked required security certifications.

What’s the difference between SOC 2 Type 1 and Type 2?

Type 1 evaluates control design at a single point in time. Type 2 evaluates whether those controls work effectively over a period of three to twelve months. Most enterprise buyers require a Type 2 report because it proves sustained operational effectiveness.

Does GoLiveFlow have SOC 2 certification?

GoLiveFlow’s SOC 2 is currently in progress. The platform already has encryption at rest and in transit, SSO/SAML on the Enterprise plan, and role-based access controls in place. For the latest status and interim security documentation, contact the GoLiveFlow team.

What should I do if a vendor doesn’t have a SOC 2 report yet?

Request alternative evidence: a completed security questionnaire (SIG or CAIQ), proof of a signed engagement letter with a CPA firm, documentation of existing controls (encryption, access management, audit logging), or other certifications like ISO 27001. Practitioners on Reddit’s cybersecurity forums recommend asking the vendor to contractually commit to an audit completion date if they can’t produce a report today.

What are CUECs and why should I care about them?

Complementary User Entity Controls are the security measures that you as the customer must implement for the vendor’s security model to work properly. Common examples include enforcing MFA for your users, promptly disabling accounts for departed employees, and regularly reviewing permissions. Ignoring CUECs can undermine even the most secure vendor.

Which Trust Services Criteria should an implementation platform include in its SOC 2?

At minimum, Security (it’s mandatory). For SaaS implementation platforms, Security + Availability is the most common combination. If the platform handles sensitive business data, documents, or financial information, adding Confidentiality is a smart requirement.

Does GoLiveFlow support SSO and on which plan?

GoLiveFlow offers SSO/SAML on its Enterprise plan, priced at $99/month per seat. View all plan details and feature comparisons on the pricing page.

How long is a SOC 2 report valid?

SOC 2 certification is valid for 12 months. Annual audits are required to maintain compliance. If a vendor’s report is older than 12 months, request a bridge letter for the gap period or ask when the next audit report will be available.