SIG Lite vs SIG Core: 2024 Shared Assessments Gap Assessment
Geert WarmenbolApril 29, 2026
Key takeaways
Organizations using SIG Lite for all vendors miss an average of 35% of critical vulnerabilities compared to organizations using a risk-tiered approach that applies SIG Core to high-criticality vendors (Vulnox assessment data, 2024).
SIG Lite covers fewer than 200 questions and is appropriate for vendors with limited access to sensitive data; SIG Core covers over 800 questions and is required for vendors handling regulated data or providing critical business functions.
The most common SIG program failure is not choosing the wrong questionnaire version -- it is sending the questionnaire and accepting responses without independent validation of whether the controls described actually exist in the vendor environment.
SIG Core Article AS-5 encryption requirements are the most frequently failed control in fintech vendor assessments: Vulnox found 1.2TB of exposed data including unencrypted SSNs at one fintech where auditors accepted the documented data classification policy without checking production systems.
Configuration drift -- the gap between documented baselines in Ansible playbooks and actual production system state -- is not addressed by SIG Core CM-7 guidance and is the primary mechanism by which compliant SIG responses mask exploitable vendor environments.
TL;DR
The SIG Lite vs SIG Core decision is secondary to the vendor tiering decision that should precede it. Most organizations choose a questionnaire version before they have classified their vendors by data sensitivity and operational criticality, which means the version choice is often wrong in both directions: Core applied to low-risk vendors who do not need it, Lite applied to critical vendors who do. Vulnox data shows a 35% critical vulnerability miss rate in programs that have not implemented risk tiering. The questionnaire is only as useful as the validation process behind it.
The onboarding call where the questionnaire is already done
The statement arrives early in most Vulnox vendor risk onboarding calls: ''We''ve got this -- we already sent our vendors the SIG questionnaire.'' It is said with confidence. The questionnaire went out, responses came back, the program is running. What comes next in the call is almost always a version of the same discovery: the organization sent SIG Lite to every vendor regardless of criticality, accepted attestations without verification, and has no process for checking whether the controls described in vendor responses exist in vendor production environments.
The questionnaire is not the assessment. It is the start of one. A vendor''s completed SIG response tells you what their security program looks like on paper as of the date they filled it out. It does not tell you whether those controls are implemented, whether they cover the systems that handle your data, or whether the configuration that was hardened for the audit is the same configuration running in production three months later. The gap between the response and the reality is where third-party risk actually lives.
SIG Lite vs SIG Core: where the coverage actually diverges
SIG Lite
Fewer than 200 questions covering fundamental security controls: access control basics, high-level data handling, incident response existence. Suitable for vendors with limited access to sensitive data, no regulatory data handling, and low operational criticality. The brevity that makes it manageable also makes it insufficient for complex environments. SIG Lite does not have the question depth to surface misconfigurations in multi-cloud architectures, assess vendor encryption implementation at the control level, or evaluate whether incident response plans have been tested against realistic scenarios.
Use SIG Lite for vendors that do not touch regulated data, are not operationally critical, and where a breach would not trigger regulatory notification requirements. If your vendor tier classification is accurate, SIG Lite covers a large portion of your vendor population at low assessment cost. If your tier classification is incomplete, SIG Lite applied to miscategorized vendors produces false confidence.
SIG Core
Over 800 questions spanning access control, data security, encryption, incident response, business continuity, configuration management, and more. Includes article-level requirements that map to specific regulatory obligations under HIPAA, GDPR, and PCI DSS. SIG Core Article AS-5 addresses encryption-at-rest implementation specifically enough to surface misclassified data stores. SIG Core CM-7 addresses configuration management with enough granularity to identify drift between documented baselines and production systems -- if the responses are validated rather than accepted.
Use SIG Core for vendors handling regulated data, providing operationally critical services, or where a breach would require regulatory notification. The resource cost of reviewing SIG Core responses accurately is significant -- one fintech client noted their review cost exceeded the cost of external validation, which is the correct economic signal: external validation is cheaper and more reliable than internal review of 800-question vendor responses.
Why the questionnaire version is the wrong first decision
The SIG Lite vs SIG Core decision has a dependency that most vendor risk programs skip: vendor tiering. You cannot choose an appropriate assessment depth before you have classified vendors by data sensitivity, operational criticality, and regulatory exposure. Organizations that choose a SIG version first and tier vendors second -- or never -- end up with a questionnaire strategy that is disconnected from their actual risk profile.
Vendor tiering requires three inputs: what data the vendor accesses (specifically whether it includes regulated data categories), what operational functions the vendor provides (whether a vendor failure would disrupt core business operations), and what the breach notification consequence would be (whether a vendor compromise triggers your regulatory reporting obligations). These inputs determine whether a vendor is low-risk (SIG Lite is sufficient), medium-risk (SIG Lite with supplemental questions), or high-risk (SIG Core with evidence validation).
The operational failure mode that produces the 35% critical vulnerability miss rate is not sending SIG Lite to a vendor that needed SIG Core. That is part of it. The larger failure is the validation gap that applies regardless of questionnaire version: organizations send either version, receive a completed response, and treat the response as evidence of control existence. A vendor can accurately describe a security control that is not implemented in their production environment. A vendor can describe a patching cadence that applies to the systems they showed the auditor and not to the systems that handle your data. The questionnaire captures the vendor''s description of their program. It does not capture the program.
Example
In a Vulnox assessment of a fintech vendor ecosystem, one vendor had completed SIG Core and described their data classification program, encryption-at-rest implementation, and access control architecture in detail. The responses were accurate for the documented environment. In production, 1.2TB of customer data including unencrypted social security numbers and bank account details was stored in AWS S3 buckets classified as ''internal'' rather than PII. SIG Core Article AS-5 encryption requirements applied to PII. They did not apply to data classified as internal. The classification was wrong. The SIG response reflected the classification.
Configuration drift is the mechanism that allows accurate SIG responses to mask exploitable production environments over time. A vendor hardens their environment for assessment, generates accurate SIG responses, and then allows configuration drift as operational changes accumulate. An unpatched Apache Struts instance that exists in production but is not reflected in documented configuration baselines is invisible to SIG CM-7 review. It is visible to a penetration test or an authenticated configuration scan.
Three findings that contradicted what organizations believed about their vendor programs
Assessment base: Vulnox assessment data, 2024, vendor risk management programs across financial services, healthcare, and SaaS sectors
35% critical vulnerability miss rate in programs without risk tiering
Across Vulnox assessments of vendor risk management programs, organizations using SIG Lite for all vendors missed an average of 35% of critical vulnerabilities compared to organizations using a risk-tiered approach. The missed findings were concentrated in vendors that had been classified as low-risk based on vendor category rather than on data access and operational criticality assessment.
Organizations believed their SIG program provided baseline coverage across their vendor population. The 35% miss rate was not a function of SIG Lite''s question depth -- it was a function of applying SIG Lite to vendors that were misclassified as low-risk. The questionnaire version was correct for the tier. The tier was wrong for the vendor.
1.2TB of exposed fintech data behind a completed SIG Core response
A fintech vendor had completed SIG Core with detailed responses on data classification and encryption-at-rest under Article AS-5. Production assessment found 1.2TB of customer data including unencrypted SSNs and bank account details in AWS S3 buckets classified as internal rather than PII. The SIG Core response was accurate for the documented data classification. The classification was wrong. The auditor had accepted the documented policy without validating production data labeling.
The client''s vendor risk program had treated the SIG Core completion as evidence of AS-5 compliance. It was evidence of the vendor''s documented classification policy. Those are different things. Validating encryption-at-rest compliance under AS-5 requires checking whether the classification applied to production data stores matches the classification that triggers encryption requirements -- not whether the encryption policy is documented.
TLS 1.2 with weak cipher suites in a healthcare vendor confirmed as crypto-compliant
A healthcare provider''s third-party appointment scheduling API was negotiating TLS 1.2 with weak cipher suites including TLS_RSA_WITH_AES_128_CBC_SHA, failing SIG Lite Article CRYPTO-2 requirements for secure data transmission. The vendor''s SIG Lite response had confirmed cryptographic compliance. The auditor had accepted vendor-provided documentation rather than independently testing the TLS configuration. The configuration exposed patient data to downgrade attacks.
Cryptographic compliance attestation without technical validation is worth the time it took to generate the attestation. TLS configuration is testable in minutes with tools like testssl.sh or sslyze. The vendor''s response described their intended cryptographic policy. The production API was negotiating something different. These are not equivalent, and treating them as equivalent is the operating assumption most SIG programs run on.
SIG Core completion is not evidence of SIG Core compliance
Common belief
Organizations that require critical vendors to complete SIG Core assume that a completed, detailed 800-question response demonstrates that the vendor has implemented the controls described. The reasoning is that SIG Core''s specificity forces vendors to describe their actual implementations rather than aspirational policies.
What we found
The fintech finding -- 1.2TB of unencrypted PII behind a completed SIG Core AS-5 response -- is not an outlier. It is a specific instance of a pattern Vulnox sees consistently: SIG Core responses that are accurate for the documented environment and inaccurate for the production environment where your data actually lives. The documentation and the deployment are different systems. The questionnaire covers one of them.
SIG Core''s specificity forces vendors to describe their security programs in detail. It does not force those descriptions to be accurate, and it does not require that the described controls exist in the systems that handle your data rather than the systems that were reviewed for the response. A vendor with a well-documented security program and a production environment that has drifted from that documentation will produce a detailed, accurate-sounding SIG Core response that does not reflect the exploitable environment you are connected to.
The validation gap is larger for SIG Core than for SIG Lite precisely because SIG Core responses are more detailed. Detailed responses are harder to audit without domain expertise, require more time to review thoroughly, and create a surface area where specific inaccuracies can hide inside correct surrounding context. One Vulnox client noted their internal review cost for SIG Core responses exceeded the cost of commissioning external technical validation -- which is the correct economic signal. If it costs more to review the response internally than to test the vendor environment externally, the testing is the better investment.
What neither SIG version addresses
Configuration drift between documented baselines and production systems
SIG Core CM-7 addresses configuration management. It does not specifically address the gap between configurations documented in infrastructure-as-code tools like Ansible playbooks and the actual state of production systems. Organizations using IaC for configuration management often have drift between the playbook and the deployed state: a playbook that specifies a patched Apache Struts version, a production system running an older version because the playbook was not executed after a maintenance change. The SIG response reflects the playbook. A penetration test finds the production system.
Object storage metadata retention after content deletion
SIG Lite Article DATA-3 addresses data retention and disposal. It does not address metadata retention in object storage systems. A vendor that securely deletes file content in S3 but does not delete associated metadata -- file names, creation timestamps, access logs, object tags -- leaves a recoverable record that can be used to reconstruct user identities and historical access patterns. This is not a hypothetical attack vector. Object storage metadata is routinely overlooked in data disposal processes because the metadata is stored separately from the content and is not surfaced by standard data deletion workflows.
Continuous authorization in cloud-native vendor environments
SIG assessments capture vendor security posture at a point in time. Cloud-native vendor environments change continuously: new services deployed, IAM permissions modified, network configurations updated. A SIG response completed in Q1 describing the vendor''s cloud security architecture may not reflect the architecture in Q3. Neither SIG Lite nor SIG Core includes requirements for continuous attestation or automated evidence collection that would surface changes between assessment cycles. The gap between point-in-time assessment and continuously changing environments is where supply chain risk accumulates.
Two directions the SIG program is heading that most organizations are not prepared for
Within 24 months, at least one major regulatory enforcement action will cite a financial institution''s failure to validate SIG questionnaire responses technically -- not just document their receipt -- as a contributing factor in a third-party breach penalty.
Regulatory guidance on third-party risk is moving toward requiring evidence of control validation, not just evidence of assessment completion. OCC, FFIEC, and DORA all reference the need for ongoing monitoring and validation of vendor controls. When a breach occurs at a vendor whose SIG response was accepted without technical validation, the regulator''s question will be: what did you do to confirm the vendor''s responses were accurate? ''We reviewed the questionnaire'' is not going to be a sufficient answer as enforcement precedent develops.
Confidence: highNo regulatory enforcement action citing SIG response validation failure specifically within 24 months would reduce confidence, though enforcement actions citing inadequate third-party oversight generally would not falsify it.Shared Assessments will add a continuous attestation module to SIG Core within 18 months, driven by demand from financial services firms subject to DORA and OCC third-party risk guidance that exceeds what point-in-time questionnaires can satisfy.
DORA Article 28 requires ongoing monitoring of critical ICT third-party providers. OCC guidance on third-party risk increasingly references continuous monitoring. The point-in-time SIG model satisfies neither requirement fully. Shared Assessments has added modules in response to regulatory pressure before -- the 2024 release reflects DORA influence. The pressure for continuous attestation capability is building from the regulatory side faster than the industry is moving.
Confidence: mediumNo SIG continuous attestation module within 18 months, or a module released as advisory rather than as a structured assessment framework, would indicate the prediction was early on timing.
The validation problem is not a resource problem -- it is a program design problem
The most common response to the SIG validation gap is that organizations lack the resources to technically validate every vendor response. That is true and is not the point. The point is that most vendor risk programs are designed as if accepting questionnaire responses is equivalent to validating them, and no amount of additional resources applied to reviewing more questionnaire responses closes that gap.
The program design question is: for which vendors, for which controls, does your risk exposure justify technical validation rather than attestation review? The answer is a subset of your vendor population -- the critical vendors, the ones handling regulated data, the ones where a breach triggers your notification obligations. For that subset, the cost of external technical validation -- testing TLS configuration, running authenticated scans against vendor-exposed infrastructure, reviewing IAM policy exports -- is lower than the cost of a breach that a validated control would have prevented.
The Vulnox fintech finding illustrates the arithmetic. A technical validation that checked whether S3 data classifications matched encryption-at-rest requirements would have found the 1.2TB exposure before it became an incident. That validation costs less than the incident response, regulatory notification, and customer notification that followed.
Counterargument
The counterargument is that requiring technical validation of vendor controls creates friction that vendors will resist, increasing assessment cycle times and straining vendor relationships. This is a real operational constraint for large vendor populations. The answer is not to abandon technical validation -- it is to apply it selectively to the vendors where the risk justifies the friction. Tiering exists for this reason. SIG Lite exists for this reason. The tiering decision, made accurately, determines where technical validation is worth the friction and where questionnaire review is sufficient.
One thing to do this week
Pull your vendor list and tag each vendor with three attributes: whether they handle regulated data categories, whether their failure would disrupt a core business function, and whether their breach would trigger your regulatory notification obligations. Any vendor with one or more yes tags is a candidate for SIG Core rather than SIG Lite -- and more importantly, is a candidate for technical validation of at least the highest-risk controls in their response. If you have not done this classification and your vendor risk program is running on questionnaire acceptance alone, the 35% miss rate in Vulnox data is a reasonable estimate of what your program is currently missing.
Further Reading
Gap Analysis
framework gap analysisWhich Framework
SIG questionnaire framework mappingNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideThird-Party Risk Management
third-party risk management overviewSOC 2 vs NIST vs ISO Comparison
SOC 2 NIST ISO comparison
Frequently Asked Questions
What is the real difference between SIG Lite and SIG Core for vendor risk management?
SIG Lite covers fewer than 200 questions focused on fundamental security controls and is appropriate for vendors with limited access to sensitive data and low operational criticality. SIG Core covers over 800 questions including article-level requirements that map to HIPAA, GDPR, and PCI DSS obligations. The practical difference is not just question depth -- SIG Core includes controls like AS-5 encryption-at-rest requirements and CM-7 configuration management guidance that are specific enough to surface misconfigurations that SIG Lite would not capture. Organizations using SIG Lite for all vendors miss an average of 35% of critical vulnerabilities compared to a risk-tiered approach, per Vulnox assessment data.
How do you choose between SIG Lite and SIG Core for a specific vendor?
The choice depends on three vendor attributes: whether the vendor accesses regulated data categories (PII, PHI, payment card data), whether vendor failure would disrupt core business operations, and whether a vendor breach would trigger your regulatory notification obligations. A vendor with any one of these characteristics is a SIG Core candidate. The vendor tiering decision should precede the questionnaire version decision -- organizations that choose a SIG version before classifying their vendors end up with questionnaire strategy disconnected from their actual risk profile.
Why do organizations fail third-party audits even after sending SIG questionnaires to all vendors?
Sending the questionnaire and accepting the response are not equivalent to validating that vendor controls exist in production. Vulnox found 1.2TB of unencrypted PII at a fintech vendor behind a completed SIG Core response -- the response was accurate for the documented data classification policy, but the production classification was wrong. Auditors accepted the documented policy without checking production data stores. The SIG questionnaire captures the vendor's description of their security program. Technical validation is required to confirm whether the described controls are implemented in the systems that handle your data.
What does technical validation of SIG responses actually involve?
For cryptographic controls like SIG Lite CRYPTO-2, technical validation means testing TLS configuration directly using tools like testssl.sh or sslyze rather than accepting vendor attestation. For encryption-at-rest under SIG Core AS-5, it means verifying that production data store classifications match the classifications that trigger encryption requirements -- not reviewing the encryption policy document. For configuration management under CM-7, it means comparing production system configurations against documented baselines to detect drift. The scope of technical validation should be focused on the controls where misrepresentation creates the highest breach risk.
What SIG coverage gaps exist that neither Lite nor Core addresses?
Two gaps Vulnox has identified that are not covered by either version: object storage metadata retention after content deletion (SIG Lite DATA-3 addresses content disposal but not metadata in systems like AWS S3), and configuration drift between IaC-documented baselines and production system state (SIG Core CM-7 addresses configuration management but not the gap between Ansible playbooks and deployed configurations). A third structural gap is continuous attestation -- neither SIG version has a mechanism for capturing changes in vendor environments between assessment cycles, which is increasingly required by DORA and OCC third-party risk guidance.
How often should SIG assessments be conducted and what triggers an off-cycle reassessment?
Annual SIG assessments are the standard cadence for most vendor populations. Off-cycle reassessment should be triggered by vendor infrastructure changes that affect the systems handling your data, vendor breach notifications (even if your data was not affected), significant changes in the vendor's regulatory environment or ownership structure, and any finding during continuous monitoring that suggests the vendor's security posture has changed materially. For critical vendors handling regulated data, some organizations are moving to semi-annual assessment cycles in response to DORA continuous monitoring requirements.
Why did my auditor reject our SIG process even though all vendors responded?
Auditors increasingly distinguish between evidence of questionnaire completion and evidence of control validation. Receiving completed SIG responses demonstrates that you sent questionnaires -- it does not demonstrate that you validated the accuracy of vendor responses or that you applied appropriate questionnaire depth for each vendor's risk tier. Regulatory guidance on third-party risk from OCC, FFIEC, and DORA references ongoing monitoring and validation of vendor controls, not just assessment completion. An auditor following this guidance will ask what you did to confirm vendor responses were accurate for the critical vendors in your ecosystem.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.