01 · Scope
Scope and boundary
We agree the systems, environments, data types, review period, and exclusions in writing before any evidence is collected, with a stated reason for each exclusion.
DSE Cybersecurity · Technical security assessment
Find the vendor access that doesn't match the data you share.
A point-in-time review of the third-party tools, SaaS applications, contractors, and connected apps that touch company or client data. We work from the evidence you can produce, tier the vendors by the risk they actually carry, and flag the access grants that should be removed or tightened. Scoped to non-AI vendor and SaaS risk.
For the leader who owns third-party risk. Advisory and readiness work. Not an audit, not a certification, not a penetration test of any vendor.
Scope boundary
Non-AI vendors. AI vendors have their own lane.
This review is scoped to conventional third-party and SaaS security risk. If the risk is specific to an AI vendor, an embedded model, or an API-connected AI tool, that scope belongs to our vendor and third-party AI risk review, which assesses how those models are governed and what data they touch. Where both apply, we sequence them rather than double-count the work.
Named methodology
One method. Which vendors matter, and why.
The Third-Party and SaaS Security Review Method follows DSE's bounded-evidence assessment method: a bounded evidence request, focused interviews, a business-context severity rating, and a roadmap with named owners. The lane-specific layer is a vendor tiering and access map covering data sensitivity, connection type, standing access, and the security evidence each vendor can actually produce.
02 · Evidence
Bounded evidence request
A defined request for client-provided exports, screenshots, screen shares, and documents. We do not request administrator credentials and we do not run automated scans.
03 · Interviews
Focused interviews
Short, targeted conversations with the people who own the controls, to test how the design actually operates rather than how a diagram says it should.
04 · Rating
Business-context severity
We rate each observed gap by likelihood and business impact, and record evidence strength alongside it. Severity is a business-context rating, not a vulnerability score, and the method is explained in the report.
05 · Findings
Evidence-linked findings
Each finding states what we observed, why it matters, the supporting evidence, the recommended action, and a named accountable owner.
06 · Roadmap
Roadmap with named owners
Immediate actions and a sequenced roadmap that balances risk reduction, dependencies, effort, and cost, with named owners and an executive readout for leadership.
Typical timebox: 2 to 4 weeks after kickoff and timely evidence access. Larger, multi-environment, or high-complexity engagements are scoped separately. Fees are scoped after the diagnostic and confirmed in writing before work begins.
Evidence reviewed
What we review, and what we do not touch.
We assess a client-provided vendor and SaaS inventory, connected-app and OAuth grant exports, data-flow and data-classification documentation, existing vendor security questionnaires and reports you already hold, and contract or data-processing terms where they bear on access. Screen shares fill gaps a static export cannot.
We do not request administrator credentials, we do not connect tooling to your environment, and we do not run automated scans or test any vendor's systems. The review is manual and evidence-based.
Deliverables
Named artifacts. Not a slide deck.
01
Vendor and SaaS inventory
A consolidated inventory of the third-party tools, SaaS applications, and connected apps in scope, with the data each touches and how it connects.
02
Risk-tiered vendor register
Every vendor tiered by data sensitivity and access, with the evidence you produced, a business-context severity, an accountable owner, and a review date.
03
Connected-app and access findings
OAuth grants, standing integrations, and contractor access reviewed against least-privilege intent, with the high-risk grants flagged for removal or tightening.
04
Minimum-evidence expectations
A right-sized set of security evidence expectations per vendor tier, so renewals stop asking every vendor for everything and start asking the right vendors for the right proof.
05
Concentration and dependency read
Where critical dependencies and single points of failure sit across the vendor set, described in business terms.
06
Prioritized remediation roadmap
Immediate actions and a sequenced plan balancing risk reduction, dependencies, effort, and cost, with an executive readout.
Sample output
A register leaders can act on.
Synthetic sample — not client data. It contains no client information and is not a finding about any organization.
The sample table scrolls horizontally on smaller screens. Keyboard users can focus the labeled table region and use horizontal navigation.
| Vendor tier | Observed evidence | Severity | Recommended move |
|---|---|---|---|
| Tier 1 · handles client data | A connected app holds broad write scopes granted for a one-time migration two years ago and never revoked. | High | Revoke the unused scopes, confirm current need, record the grant owner. |
| Tier 2 · internal tooling | The vendor cannot produce a current security report and the contract predates the data-processing terms. | Moderate | Request current evidence, refresh the terms at renewal, set a review date. |
| Tier 3 · low-sensitivity | Access is appropriate, but no accountable owner is recorded for the renewal decision. | Low | Assign a renewal owner and a minimum-evidence expectation for the tier. |
Final ratings depend on the vendor set, the evidence, and the agreed method. We do not convert findings into a purported certification score.
Frameworks referenced
Framework structure, no vendor claims.
We organize findings using NIST CSF 2.0, with attention to the Govern function's supply-chain outcomes, and reference CISA's Cross-Sector Cybersecurity Performance Goals as a supporting baseline. These frameworks shape how we describe outcomes; they do not make this an audit.
How the work is delivered
Accountable delivery, disclosed clearly.
DSE delivers through documented in-house expertise and qualified specialists from our expert network, selected for the technologies and risks in scope. DSE remains accountable for scope, quality, integration, and outcomes. Where specialist or partner delivery is involved, we disclose that role clearly.
Accountable owner: DSE delivery leadership.
Clear boundaries
Evidence-based advice, not assurance.
This is a point-in-time assessment of the vendors, SaaS tools, connected apps, and documentation in the agreed scope. It is not legal advice, not an audit, not a certification, and not an attestation. It does not guarantee compliance or any enforcement or examination outcome. It does not make your organization secure and does not prevent, detect, or reduce the likelihood of any security incident; it documents risk against a defined scope at a point in time. DSE does not operate a 24/7 security operations center, does not provide continuous monitoring or managed detection and response, does not perform live incident response or digital forensics and incident response (DFIR), does not run penetration tests, and does not resell licenses. Where you need any of those, we help you scope the requirement and select a provider you contract directly. Remediation implementation is performed only where it is separately scoped in writing. Counsel, auditors, and assessors retain their respective roles.