What it is
External posture monitoring scans a vendor's public domain from the outside — the same vantage point an attacker has — and grades how well the vendor protects email and web traffic. It's a lightweight, no-questionnaire-required signal of a vendor's security hygiene that you can collect on every vendor automatically. The approach is similar to SecurityScorecard or BitSight, scoped to the checks TATER can verify directly and at no extra cost.
What gets checked
- SPF record — is a Sender Policy Framework record published? (Missing SPF means the vendor's domain can be spoofed in phishing aimed at you.)
- DMARC policy — is DMARC published, and how strong is it?
p=rejectis the strongest;quarantine/noneare weaker (warning). - TLS certificate — does the site serve a valid certificate over HTTPS, who issued it, and how many days until it expires? An expired or near-expiry cert is a red flag.
- HSTS — does the site enforce HTTPS via HTTP Strict Transport Security?
Each check contributes to a weighted 0-100 score (TLS and DMARC weigh most) that maps to a letter grade A-F. Checks that can't run (for example a domain that doesn't resolve to a public address) are skipped, not counted against the vendor.
Scanning a vendor
- Open Vendors (Assets group) in TATER Security and click a vendor to open its detail page.
- Make sure the vendor has a Website on record (External Posture uses the website domain).
- Click 🔍 Scan Posture in the header. Within a few seconds the External Security Posture card shows the grade, score, scanned domain, and a per-check breakdown.
Continuous monitoring
A nightly sweep automatically re-scans every vendor that has a website, so the posture grade and the certificate-expiry watch stay current without anyone clicking a button. New vendors are picked up on the next nightly run; you can always trigger an immediate scan with the button.
Fleet view & reporting
- Insights → Vendor External Posture shows the grade distribution across all your vendors, average score, how many are failing (score under 60), and which vendor certificates expire within 30 days.
- External posture is stored on the vendor record (
externalPostureScore,externalPostureGrade), so it travels with the vendor in vendor risk reviews and exports.
Vendor complaints
Complaints capture issues raised against a vendor — a missed SLA, a billing dispute, a security incident, poor support — so they're logged, tracked to resolution, and visible in the vendor's risk history rather than scattered across inboxes. A recurring pattern of complaints is itself a posture signal worth surfacing in a renewal or risk review.
- Log a complaint — open a vendor's detail page and record the complaint with a title, description, category (e.g. service, billing, security, compliance), and severity. Each complaint opens in
openstatus. - Track status — move a complaint through its lifecycle (
open→investigating→resolved/closed) as you work it, so nothing falls through the cracks. - Record the resolution — capture how the complaint was resolved and when, building an auditable trail on the vendor record that feeds vendor risk reviews and exports.
For AI agents, create_vendor_complaint (write, Admin) logs a complaint, update_vendor_complaint (write, Admin) advances its status and records the resolution, and list_vendor_complaints (read) returns complaints across vendors.
Permissions: any member can view complaints; logging, updating, and resolving a complaint requires the Admin role.
Vendor on-site reviews & visits
Some vendors — data centers, managed service providers, fulfillment partners — warrant an on-site assessment or visit rather than a remote questionnaire. On-site reviews let you schedule a visit, record what was observed, and log findings against the vendor so the assessment lives in the vendor's risk history alongside posture scans and complaints.
- Schedule a visit — from a vendor's detail page, create an on-site review with a scheduled date, the location or site, and the reviewers attending.
- Record findings — during or after the visit, add findings (observations, gaps, or remediation items) to the review so each is tracked individually with its own severity.
- Close out the review — mark the review complete with an outcome and summary; completed reviews and their findings stay on the vendor record for audit and renewal decisions.
- Stay ahead of due dates — upcoming and scheduled reviews surface so visits aren't missed.
For AI agents, create_vendor_onsite_review (write, Admin) schedules a visit, append_vendor_onsite_finding (write, Admin) adds a finding, complete_vendor_onsite_review (write, Admin) closes it out, and list_vendor_onsite_reviews / list_upcoming_vendor_reviews (read) return reviews and what's due.
Permissions: any member can view on-site reviews; scheduling visits, adding findings, and completing reviews requires the Admin role.
Vendor portal access
Sometimes the fastest way to close a questionnaire or collect a SOC 2 report is to let the vendor do it themselves. The Portal Access tab on a vendor's detail page issues a time-limited token that is designed to let a named contact at that vendor answer their open questionnaires and attach evidence — without a TATER account, an invite, or a licence seat.
Token issue, list, and revoke all work, and the API endpoints a vendor portal would call are shipped and enforced. What is not shipped is the page at the other end of the link: app.tatersecurity.com/vendor-portal.html does not exist yet, so a vendor who clicks the URL is routed to the TATER sign-in hub instead of a vendor form — which they cannot get past. Do not send these links to vendors yet. Collect questionnaire responses and evidence the way you do today until the portal page ships. The rest of this section documents the token controls as they behave now, so that the access you have already issued can be reviewed and revoked.
Issuing a token
Open the vendor, go to Portal Access, and click + Issue Token:
| Field | Notes |
|---|---|
| Recipient name / email (required) | The individual at the vendor, not a shared alias. Everything they submit is attributed to this identity in the Activity Log, so a group mailbox destroys the audit trail. |
| Expires in | 7, 30, 90, or 180 days. Pick the shortest window that covers the task — the link works until it expires or you revoke it. |
| Purpose | Questionnaire, evidence, or general. A label for your own records. |
| Can respond to questionnaires | Allows the token to read the questionnaires assigned to this vendor that are still open and to submit answers against them. |
| Can upload evidence | Allows the token to attach evidence against the vendor record. Uploads land on the vendor as evidence entries, tagged as coming from the portal. |
Both capability boxes default to on. Untick the one you don't need — a token issued for a questionnaire has no reason to accept evidence, and the capability is enforced on the API, not just hidden in the UI: a request that exceeds the token's grant is rejected outright.
The URL is the bearer token — anyone holding it has the access it grants, with no sign-in and no second factor. TATER shows it exactly once, at issuance, and never again; the token list afterwards shows only an 8-character prefix. Treat it like a password: don't paste it into a shared channel or a ticket, and don't forward it onward. If it goes astray, revoke it (below) and issue a fresh one rather than hoping.
Watching and revoking
The Portal Access tab lists every token issued for the vendor with its recipient, purpose, expiry, which capabilities it carries, how many times it has been used and when it was last used, and whether it is Active, Expired, or Revoked. The access count is worth a glance — a token used far more often than the task warranted, or used after the work was finished, is worth revoking.
Revoke on any active token kills it immediately: every request carrying that token is rejected from then on, whoever holds it. Revoke when the questionnaire comes back, when your contact leaves the vendor, or the moment you suspect the link has been forwarded. Revocation is permanent — issue a fresh token if access is needed again. Expired tokens stop working on their own and need no action.
The Revoke button appears only on tokens that are still active — an expired or already-revoked row has nothing left to revoke. Tokens issued before revocation support shipped are covered as well: opening the tab assigns them a revocation handle in place, so they show a working Revoke button like any other.
Permissions: issuing, listing, and revoking portal tokens all require the Admin role. Issuance and revocation are audit-logged, and anything submitted through a token is recorded against the recipient's name and email with the vendor portal as the source.
Vendor contracts & renewals
A vendor's Contracts tab tracks the paper behind the relationship — MSAs, SOWs, DPAs, NDAs, order forms, subscriptions — so a term never lapses unnoticed and the commercial picture sits next to the risk picture. Contracts ship with every TATER Security license; there is no separate module to enable.
Recording a contract
Open a vendor's detail page, go to the Contracts tab, and click + New Contract:
| Field | Notes |
|---|---|
| Title (required) | What the document is called. Max 300 characters. |
| Type | MSA, SOW, DPA, NDA, Order Form, Subscription, or Other. |
| Contract # | Your or the vendor's reference number. |
| Start date / End date | The term. End date is what drives everything below — a contract with no end date never appears on the renewals page. |
| Value | Free-form, so write it however your finance team reads it ("$120K/yr"). |
| Notice days | How far ahead of the end date the contract should start flagging as Expiring. Defaults to 60 — set it to the notice period your contract actually requires, not a round number. |
| Auto-renews | Marks contracts that roll over if nobody acts. These are the dangerous ones — an auto-renewing contract you meant to cancel is the whole reason for the notice window. |
| Contract URL | Link to the executed document wherever it lives (SharePoint, a DMS, the vendor's portal). |
| Notes | Anything else worth carrying into the renewal conversation. |
Status is derived, not typed. TATER computes it from the end date against the notice window each time the contract is read: past the end date is Expired, inside the notice window is Expiring, otherwise Active. Draft, Terminated, and Superseded are sticky and are never overwritten by the date math. This means you cannot forget to update a status — but it also means a wrong end date silently produces a wrong status, so get the dates right.
The Contract Renewals page
Vendors & TPRM → Contract Renewals is the cross-vendor view: every contract whose end date falls inside a window you choose (30 / 60 / 90 / 180 / 365 days, defaulting to 90), sorted by urgency. Each row shows the vendor, the contract, its type, the end date, the days remaining, the value, and whether it auto-renews. Anything already past its end date is called out in red as OVERDUE, and the header keeps a running count. Click a row to jump to the vendor; click Renew to renew in place.
Contract expiries also land on the GRC Calendar (a year ahead), so they show up alongside your other compliance due dates rather than only on this page.
Renewing
Renew takes a new end date, optionally a new value, and notes. It pushes the end date forward, updates the value if you supplied one, re-derives the status, and appends an entry to the contract's renewal history (who renewed it, when, the new term, the notes) — the last 25 renewals are kept. Use Renew for an actual term extension; to correct a title, type, or note without changing the term, use Edit instead, which does not write a renewal record.
Terminating vs. deleting
These are deliberately different actions:
- Terminate ends a contract early. The record stays, its status becomes
Terminated, and the termination date and reason are stamped on it — so the history of why the relationship ended survives an audit. Requires Admin. - Delete removes the record entirely. Use it only for a contract entered in error. Requires Admin.
The vendor Contracts tab offers Renew and Edit; there is no Terminate button in the UI yet. Terminate a contract with the terminate_vendor_contract MCP tool or POST /api/vendor-contracts/{id}/terminate. Editing the contract and leaving it to expire is not equivalent — it records no reason and no termination date.
For AI agents (MCP)
list_vendor_contracts(read) — browse contracts, filtered by vendor or derived status.list_upcoming_contract_expiries(read) — what falls due inside a window (default 90 days), overdue included. This is the one to ask for before a renewal planning meeting.create_vendor_contract(write, Auditor+) — create, or upsert by passing an existingid. Also accepts signers and clauses (liability cap, data protection, SLA, right-to-audit, subprocessor, termination, pricing, renewal), which the web form does not yet expose.renew_vendor_contract(write, Auditor+) — record a renewal againstcontract_idwith anew_end_date.terminate_vendor_contract(write, Admin) — end early with a reason.delete_vendor_contract(write, Admin) — remove the record entirely.
Permissions: Viewer and above can see contracts and the renewals page; creating, editing, and renewing needs Auditor; terminating and deleting need Admin. Every action is audit-logged.
DocuSign envelopes
A vendor record has a DocuSign tab for tracking signature requests — contracts, NDAs, security attestations — against the vendor. It lists envelopes with a status chip, and a + Send for Signature button opens a modal for the subject, message, document name/URL, and signers.
Envelope statuses are PENDING_SETUP, sent, delivered, completed, declined, voided, and error.
Signature-request tracking, dispatch not yet live. This tab currently records and tracks the envelope and its status; it does not yet call the DocuSign eSignature API to actually send the document. Use it to log and follow signature requests you dispatch through DocuSign directly. Live send/void through TATER is planned.
Configuration. There is no settings screen for this yet — an org admin sets the fields through the Settings API: docusignEnabled, docusignAccountId, docusignBaseUri, docusignIntegrationKey, docusignUserId, docusignRsaPrivateKey, docusignDefaultEmailSubject, and docusignWebhookHmacSecret. Credential fields are encrypted at rest and redacted for non-admins.
For AI agents (MCP)
Two MCP tools let an AI assistant fold external posture into a vendor risk review:
get_vendor_posture(read) — returns the latest grade/score and per-check results across vendors.scan_vendor_posture(write, Admin) — triggers a fresh scan of a specific vendor's domain.
Security & limits
- Scans only probe public domains. Domains that resolve to private, loopback, link-local, or carrier-grade-NAT addresses are rejected before any connection is made (SSRF protection) — so the scanner can't be pointed at your internal network.
- The scan is passive and lightweight: a DNS lookup plus a single TLS/HTTPS handshake. It does not log in, submit forms, or probe for vulnerabilities.
- External posture is one input to vendor risk — combine it with questionnaires, SOC 2 / ISO certifications, and contract review for a full picture.