How to get the most from Hosting Security

1. Go to security.hitthosting.com and click Sign in (or open /login directly).
2. Enter the email and password for your Hitt Hosting account and click Sign in to Hitt Hosting Security.
3. You land on the Security Center. A live scan of every product on your account runs automatically on each visit — no button to press.
4. Review the Critical / Warning / Info tiles and the per-product sections below them. Each product heading shows its status: a count of findings to review, “no abnormalities”, or “source not connected”.
5. Use the left sidebar to move between Security Center, All findings, Bank connections, and Settings.

Tip: “Source not connected” is never an all-clear: it means the scanner couldn't reach that product's tables yet, so treat it as unknown, not safe.

1. Nothing to configure: scheduled scans are on for every account automatically.
2. Each scheduled scan records what it found, emails you about new criticals (idempotently: never the same alert twice for the same finding), and delivers to any webhooks you've configured.
3. Opening the Security Center also runs a fresh live scan, so what you see is never stale.
4. To confirm your scheduled scans are firing, check the Scan history card on the Security Center. It lists every recent scan with its timestamp and finding counts.

Tip: A stalled cadence can't hide: if the “Last scan” timestamp in Scan history looks old, something is wrong. That's exactly what the card is for.

1. Open Settings from the left sidebar.
2. Scroll to the Data sources section at the bottom of the page.
3. Each subscribed product (CRM, Books, HR, Desk, Sign, Field, SE, Hosting) is listed with its status: “connected” (green) or “not connected” (yellow).
4. The Email delivery row near the top of Settings shows whether alert email sending is configured for your environment.

Tip: You don't connect products manually; anything subscribed on your Hitt Hosting account is picked up automatically by the scanner.

1. Open the Security Center from the sidebar.
2. Find the Posture over time card near the top. The big number is today's score (higher is safer), with a Green / Yellow / Red band indicator.
3. Next to the score, the “this week” delta compares against your prior snapshot: green +N means improving, red −N means regressing.
4. The small sparkline on the right shows the score's shape over time, oldest to newest.
5. Below the score card, the three tiles count your open findings by severity: Critical, Warning, and Info. Open means not acknowledged, resolved, or muted.

Tip: Watch the slope, not the absolute: a 72 trending up is healthier than a 90 trending down. On your first day the card shows “Collecting” until a second snapshot exists.

1. Open the Security Center and find the What changed since your last scan card.
2. “Appeared” lists findings new since the prior scan; “Cleared” lists findings that went away, each carrying its last-seen severity so a cleared critical reads loud.
3. Unchanged findings are shown as a count only, keeping the card focused on movement.
4. Scheduled scans update the diff too: a returning user sees what moved while they were away, not just since their last visit.

Tip: Appeared/cleared events also land on each finding's audit trail and travel with the CSV and JSON evidence exports. A finding never clears just because we couldn't reach its source; see “How to tell a clean scan from an incomplete one”.

1. Open the Security Center. On a normal scan you'll see nothing about coverage: every source answered, so there is nothing to flag.
2. When a source doesn't respond, an amber card appears at the top saying how many of your sources reported and naming the ones that didn't.
3. Open findings from a source that didn't respond are held, not cleared. They stay on your list and no “cleared” event is written to their audit trail, because nothing was verified as fixed.
4. Your posture score is not recorded for that day. You'll see a gap in the Posture over time trend rather than a jump.
5. Nothing to do: the next scan picks the source back up. Findings that reappear show as unchanged, not as new or regressed.

Tip: A source marked “not connected” on a product card is different: that means the product isn't provisioned yet, which is a real answer, so it does not hold findings or pause your score. The coverage card only appears when a source timed out or errored — when we genuinely could not look.

1. Open the Security Center and find the Scan history card.
2. The prominent “Last scan” timestamp at the top shows when the most recent scan ran.
3. Each row below is one scan, newest first, with its Critical / Warning / Info counts.
4. Delta arrows on each row compare against the immediately-prior scan, so a jump or a drop is visible at a glance.

Tip: Where the posture score is one daily number and the last-scan diff covers only the two most recent runs, Scan history shows the full per-scan cadence.

1. Open the Security Center from the sidebar.
2. Scroll to the per-product sections: each heading is the product name followed by “›”.
3. Click a product heading (for example “Books ›”) to open its dedicated page at /p/<product>.
4. The product page shows only that product's findings, with the same acknowledge and resolve actions as the main dashboard.

1. Open Check register from the left sidebar.
2. The summary line at the top counts the scan: how many checks ran, how many are findings, how many are approaching, and how many could not be checked.
3. Each check shows its title, its current value against its threshold (e.g. 4 / 5), and a status: Finding, Approaching, Clear, or Not checked.
4. Use the status filter chips to narrow the list. For example, tap “Approaching” to see only the checks that are one step from tripping.
5. Checks are grouped by product, with a Cross-cutting group for the identity, dark-web, fraud, scam, and vendor checks that run for every account.

Tip: A check we could not run shows as “Not checked” instead of counting as a pass, the same honesty rule as the data-source status. This is a record of what the scanner evaluated, not an audit or an assessment, and it makes no certification claim.

1. Open All findings from the sidebar (or work from a product section on the Security Center).
2. Findings are ordered most severe first. Each card shows the severity badge, title, detail, the affected subject, and how long ago it was first detected.
3. Read the Recommended fix box on the card: a clear corrective action generated from the finding's rule, with no AI call or waiting.
4. For bigger fixes, click “Show N steps” inside the Recommended fix box to expand the ordered step-by-step plan.
5. Work the fix, then use Resolve on the card to close the loop with a remediation note.

Tip: Finding age is anchored to when the scanner first saw the issue: it accumulates across scans instead of resetting every run, so an old finding reads as old.

1. Open All findings from the sidebar.
2. Use the search box (“Search title, detail, or subject…”) for free-text matching, or “Owner contains…” to filter by assignee.
3. Click facet chips to narrow by Severity (Critical / Warning / Info), Product, Category, and State (Open / Resolved / Muted), or toggle “Overdue only” and “Unowned only”.
4. The footer shows how many findings the current filter matches. Click Clear filters to reset.
5. To keep a slice, click Save view, type a name (for example “My overdue criticals”), and press Enter. It appears as a chip in the Views row.
6. Click any chip to reapply it; the built-in presets All open, Critical, Overdue, and Unowned work out of the box. Delete your own views with the × next to the chip.

Tip: Saved views are scoped to your account; the built-in presets can't be deleted.

1. On any open finding card, click Resolve.
2. In the “Remediation note (optional)” box, describe what you did to fix it; the note is stored as evidence and appears in exports.
3. Click Confirm resolve. The finding moves to the Resolved list on the page.
4. If a later scan sees the same finding again, it automatically reopens with a red “Regression · reopened” badge: a failed fix can't masquerade as closed.
5. To reopen a resolved finding manually, expand the Resolved section and click Reopen on its card.

Tip: Distinct from a regression, a finding that clears and returns on its own across scans gets an amber “Recurring · appeared N×” badge: an unstable control that flickers between scans can't hide.

1. To acknowledge: click Acknowledge on the finding card. It leaves the open count immediately.
2. To mute: click “Mute (accept risk)” on the card instead.
3. Answer “Why are you accepting this risk?” The reason is stored on the record.
4. Pick a duration: 30 days, 90 days, or Indefinitely, then click Confirm mute.
5. Muted findings drop out of the open count and stop triggering alerts, but stay visible in the Muted section and in evidence exports.
6. When the timer expires the finding returns automatically; to bring one back early, click Un-mute on its card in the Muted section.

1. On an open finding card in All findings, click Assign owner.
2. Type a name, email, or team (for example “ana@acme.com” or “Platform”). It's an accountability label, not a user account.
3. Click Save owner. The owner badge appears on the card and a dated “Owner assigned” entry lands on the finding's audit trail.
4. To hand it off, click Reassign owner; to remove the owner, open the editor and click Unassign.

Tip: Filter by “Owner contains…” or the “Unowned only” chip on All findings to find work by assignee; assignments also travel with the CSV and JSON exports.

1. On an open finding card in All findings, click Set due date.
2. Pick a date; it's your own remediation target, not an SLA.
3. Click Save due date.
4. The card now shows “Due in N days”, “Due today”, or, once the target slips, a red “Overdue by N days” badge, and overdue findings escalate ahead of the normal age threshold.
5. To change it later click Edit due date; use Clear to remove the target entirely.

Tip: The “Overdue only” filter chip on All findings shows everything past its target in one click.

1. On any finding card, click Add note.
2. Type your working note (for example “left a voicemail with the vendor — waiting on the maintenance window”).
3. Click Add note to save. Notes are append-only, so they stay on the record.
4. Scroll to the Audit trail section at the bottom of the card: every lifecycle event (Acknowledged, Resolved, Reopened, Muted, Owner assigned, Due date set, Comment, Appeared in scan, Cleared in scan) is listed with its timestamp, oldest first.

Tip: The full trail travels with the CSV and JSON evidence exports, so an auditor sees the same timeline you do.

1. Open All findings and (optionally) filter to the slice you care about.
2. Tick the checkbox on individual cards, or use “Select all (N open)” above the list.
3. A sticky toolbar appears showing “N selected” with the actions: Acknowledge, Resolve, Assign owner, Set due date, and Mute.
4. Acknowledge fires immediately; Resolve, Mute, Assign owner, and Set due date open a small panel for the shared note, reason, owner, or date first.
5. Each finding still gets its own state change and its own dated audit-trail entry, so the per-finding evidence record stays exact.

Tip: A failure on one finding never aborts the batch: anything that failed stays selected so you can retry.

1. Open All findings and find the open finding you want to plan.
2. Click “Plan steps” on the Remediation milestones bar of the card.
3. Type the first step's description (for example “Rotate exposed key”), pick a target completion date, and click Add step.
4. Repeat for each staged step of the fix.
5. Tick a step's checkbox when it's done; the header shows progress like “(2/3 done)”. Use Remove to delete a step, or edit its date inline.

Tip: Milestones thread into the POA&M export and the JSON evidence pack per finding: a staged plan instead of a single lump due date. Your own remediation plan, not a certification.

1. Open Settings from the sidebar and find the Escalation SLA card.
2. Set the Critical escalation window in days (1–90; default 7).
3. Set the Warning escalation window in days (1–90; default 14).
4. Click Save thresholds.
5. Findings open longer than their window are flagged as escalated, and the same windows drive the Approaching SLA breach panel and the SLA-breach rate in Remediation velocity.

Tip: These thresholds are your own targets; they only affect your account and have no bearing on any certification or external SLA.

1. Open the Security Center and find the Approaching SLA breach card.
2. Findings closest to breaching are listed first, each showing the days remaining before it crosses your configured window.
3. The header counts what's “due soon” and, in red, anything already “past window”.
4. Click through to All findings to work the list; when nothing is at risk the card says so honestly.

Tip: This is pure computation over your own finding ages and your own configured windows: an early-warning system, not a guarantee.

1. Open the Security Center and find the Remediation velocity card.
2. The table shows one row per severity with MTTR (mean days from first detected to resolved), the SLA breach rate, and how many findings closed in the window.
3. The header shows the measurement window and total closed count, so the mean is honest about its sample size.
4. Breaches are judged against the very SLA windows you configured in Settings → Escalation SLA.

Tip: Observed workflow metrics on your own data, not an SLA guarantee or attestation of compliance.

1. Answer the requirements you can in the NIST 800-171 requirement register first. A capture freezes whatever is there — including "unreviewed", which is a perfectly honest answer to have on a date.
2. Open "Assessment of record" underneath the register, give it a name ("2026 annual self-assessment"), and set the assessment date. That date is yours to set: if you finished the assessment last Tuesday, use last Tuesday, not today.
3. Add a methodology note if it helps — how you conducted it, who took part. An assessor asking "how did you arrive at this?" is asking for exactly that.
4. Click Capture. All 110 answers are copied, and the working total is computed from that copy. Once captured it cannot be edited or deleted by anyone, including you — that is what makes it a record rather than a draft.
5. Carry on editing your register as normal. The captured assessment does not move: your live answers and your record are now two separate things, which is the whole point.
6. Next time, use "What changed?" to compare any two assessments, or an assessment against today. It lists what improved, what regressed, what changed applicability, and what you answered for the first time, biggest point movement first.
7. Use the POA&M and SSP links beside an assessment to re-run those exports against THAT assessment's answers. The file is even named for the assessment's date, so last quarter's POA&M reproduces last quarter.

Tip: Two things worth knowing. First, the change history on each requirement starts the day this feature was deployed — answers you set before then have no recorded history, and we have not invented any for them. Second, and as everywhere else in this product: an assessment of record is YOUR dated record of YOUR OWN answers. Hitt Security does not perform the assessment, does not decide whether a requirement is met, computes no official SPRS score, and submits nothing to SPRS or anyone else. The working total is arithmetic on your own answers using the publicly documented DoD Assessment Methodology weighting.

1. Open "Incident register" in the sidebar and click "Record an incident".
2. Give it a title and a description, and set "Discovered at" to when you actually found it — not now. The 72-hour clock runs from discovery, so an incident found on Friday and recorded on Monday has already burned most of its window, and we show you that rather than hiding it.
3. Pick a category and severity. Tick "Affects covered defense information" if it does — that is what starts the DFARS 252.204-7012 countdown.
4. Work the incident forward one phase at a time: detected → analysing → contained → recovered → closed. Each step asks for a note, because 3.6.1 asks what you did, not just that a status moved. You cannot close an incident without a containment note and a recovery note.
5. Under "Reporting log (3.6.2)", record who you reported it to and when — a designated official internally, your prime, your customer, an authority. Add an entry per recipient. An incident with no entries reads as "not yet reported", never as compliant.
6. To satisfy 3.6.3, run a tabletop and record it with "This is an exercise" ticked. Exercises are excluded from incident counts and from the 72-hour clock, and the register shows your most recent exercise date.
7. Export your SSP from Settings and it now carries a §3.6 section built from this register.

Tip: The 72-hour countdown is YOUR clock and nothing else. Hitt Security does not submit reports to DIBNet or to any authority on your behalf, and there is no integration that would let it. Logging a report here records what you did; it is not a filing. And nothing in the register answers a requirement for you — your own assertion still drives your self-assessment score. This is the evidence, not the verdict.

1. Open Access Review from the dashboard. Grants are grouped by product (Hosting, Desk, Sign, SE, Field) — every privileged grant the scan already enumerates.
2. For each grant, click Keep (you've confirmed it's still needed) or Revoke (you intend to remove it). Your name and the date are recorded automatically.
3. A grant you've never reviewed, or whose last review is older than the quarterly cadence, shows a "review due" flag; a current one shows its last-reviewed date.
4. Export your evidence pack (Compliance & evidence → Export) and the completed reviews travel inside it, covered by the same integrity checksum as the rest of the pack.

Tip: Advisory and self-assessment only: a Revoke decision is your note to yourself for the audit trail; Security never edits the underlying product's tokens, and nothing here is a certification. Actually removing a token is still done in that product.

1. Open the Security Center and find the Compliance coverage card.
2. Each row is one control area (Access Control, Change Management & Audit Logging, Data Protection, Vendor & Supply-Chain, Account & Billing Integrity, and Identity & Credential Hygiene) with its framework references (CIS Controls v8 · OWASP · NIST CSF).
3. Read each area's status: Clear (green), Findings open (yellow, with the open count), or Source not connected (grey).
4. The header totals how many of the six control areas are covered by an active monitor on your subscribed products.

Tip: A deterministic self-assessment of your own scan, not a certification or audit. “Source not connected” is never an all-clear.

1. Open the Security Center and scroll to the Compliance coverage card.
2. Below the six control areas, find the “NIST SP 800-171 requirement families” section: all 14 families (3.1 Access Control, 3.3 Audit & Accountability, 3.5 Identification & Authentication, 3.13 System & Communications Protection, and so on).
3. Read each family's status: Covered (green), Findings open (yellow, with the open count), or Not in scope (grey) — derived only from your existing control-area coverage above, no extra scan.
4. “Not in scope” means no monitored area maps to that family: families like 3.2 Awareness & Training or 3.9 Personnel Security are outside what this scan observes, not a failing grade.
5. Export an assessor-ready POA&M (Download POA&M on All findings): every open finding's row now carries a “NIST 800-171 Requirement Family” column (e.g. “3.3 Audit & Accountability”) alongside the existing CIS/OWASP/CSF reference.

Tip: This keys your own scan output to the 800-171 vocabulary so an assessor doesn't have to translate; it does not compute an SPRS self-assessment score or claim compliance. Deterministic and offline: no AI, no network. Self-assessment, not a certification.

1. On the Compliance coverage card, find the control area you've reviewed.
2. Optionally type a short note in the “Optional note” field (for example “quarterly review done”).
3. Click Mark reviewed, or Accept risk if you're consciously accepting open findings in that area.
4. A dated Reviewed or Accepted badge appears on the row and persists across refreshes and scans.
5. Changed your mind? Click Clear mark to remove it.

Tip: Each mark carries its date and note into the JSON evidence pack, POA&M export, and branded posture report: a record of what you actually reviewed. Self-assessment, not a certification.

1. To attach evidence to a control area: open the Security Center, find the Compliance coverage card, and click Attach proof under the control area you're documenting.
2. To attach evidence to a specific finding: open All findings from the sidebar and click Attach proof on the open finding's card.
3. Type a short title for the artifact (for example “Quarterly access-review policy”).
4. Optionally paste a link to where the artifact already lives: SharePoint, Drive, your policy site. It must start with http:// or https://.
5. Optionally add a one-line description of what the artifact shows, then click Add evidence.
6. The reference appears in the list with the date you recorded it. Click Remove on any entry to take it back out.
7. Download the artifacts to see it flow through: Download SSP renders a “Supporting evidence” block under each control area that has references; Download POA&M (CSV) carries an “Evidence” column on every open finding's row; and Download JSON includes the full register in its evidence array.

Tip: We store the reference and the link, never the file; the artifact stays wherever you keep it today, and we don't hold, validate, or attest to what's at the other end. A finding's POA&M row shows the references attached to it plus the ones attached to its control areas. Self-assessment, not a certification.

1. Open All findings from the sidebar.
2. In the Export row at the top right, click Download CSV for a spreadsheet, or Download JSON for the timestamped evidence pack.
3. Both carry each finding's age, acknowledgement state, owner, notes, and full resolution evidence: resolved-on timestamp and the exact remediation note you typed.
4. The JSON pack additionally includes the compliance control-area roll-up, your control-area sign-offs, per-finding milestones, recurrence counts, and a tamper-evident integrity block.

Tip: Exports are scoped to your own account and reflect the live scan at the moment you download.

1. Open All findings from the sidebar.
2. In the Export row, click Download POA&M (CSV).
3. Each open finding becomes one row with its control reference, owner, fix-by date, and status.
4. The “Milestones with Completion Dates” column is populated from the dated milestones you planned on each finding: staged steps, not just a lump due date.
5. The Remediation Plan / Comments column is auto-filled from the built-in remediation guidance, so a fresh finding never hands an auditor a blank corrective-action cell; your own resolution or accept-risk note takes precedence when you've written one.

Tip: A self-assessment aid that helps you populate your POA&M, not a certification.

1. Open All findings from the sidebar.
2. In the Export row, click Download System Security Plan.
3. Your browser downloads a self-contained HTML document. Open it and use File → Print → Save as PDF to produce the PDF you hand to a prime or assessor.
4. Section 1 states your system boundary: the account and the subscribed Hitt Hosting products the scan covers.
5. Section 2 has one part per control area: its cross-framework references, a Clear / Findings open / Source not connected status, your dated review/accept attestation where you've marked the area (the “how we meet it” line), the Shared responsibility / inherited controls block (see “How to use the shared-responsibility matrix”), and any open findings listed as documented gaps with their recommended corrective action, cross-referencing your POA&M.
6. The footer carries the standing self-assessment disclaimer and the same integrity checksum as your JSON evidence pack, so the printed SSP is verifiable.

Tip: Mark each control area Reviewed or Accept-risk first (see “How to mark a control area reviewed”) so the SSP prints your dated attestation line for that area. A self-assessment aid, not a certification or audit.

1. Open the Security Center and find the Compliance coverage card.
2. Under any control area, click Shared responsibility to expand it.
3. Platform provides names what Hitt Hosting implements beneath your tenancy for that area: for example, row-level security isolating your records, AES-256-GCM encryption at rest for stored banking tokens, or the append-only finding-event trail.
4. You own names what stays yours: who you invite, the scope of the API tokens you mint, enforcing MFA, rotating exposed credentials, and your vendor due-diligence.
5. Shared names the middle: the control only holds if both sides act (the platform detects an exposed credential; only you can rotate it).
6. To hand the split to an assessor, export your SSP (All findings → Download System Security Plan). Each control area prints a Shared responsibility / inherited controls block you can lift into your ESP inheritance statement.
7. The matrix also travels in the JSON evidence pack, inside the same integrity checksum as the rest of the pack, so an altered line fails verification.

Tip: The split is a property of the platform, so it reads the same whether or not you have open findings. The platform-provided lines are inheritance inputs you still validate and document; they are not certified, audited, or attested controls, and describe no framework certification.

1. Open the Security Center and find the NIST 800-171 requirement register card, below Compliance coverage. It starts collapsed; click it to load your register.
2. The header shows how many of the 110 requirements you have reviewed, and the draft working total from your own answers: 110 minus the published DoD Assessment Methodology weight (5, 3, or 1 point) of every requirement you marked Not met.
3. Use the All / Unreviewed / Not met filters to pick your slice, then click a family (3.1 Access Control, 3.6 Incident Response, …) to expand its requirements.
4. For each requirement, type an optional note (how you meet it, or what the gap is) and click Met, Not met, N/A, or Clear. Your answer saves immediately and persists across reloads.
5. The grey line under each requirement is context only: its point weight, and what your scan observed for that family. The scan never sets a status; you answer every requirement yourself.
6. This is how you close the families the scan cannot see. 3.2 Awareness & Training, 3.6 Incident Response, 3.7 Maintenance, 3.9 Personnel Security, and 3.10 Physical Protection have no monitor behind them, so coverage reports them as not in scope. Mark them here and they become part of your record.
7. Export the results: All findings → Download POA&M adds one row per Not met requirement (with its id, family, owner, and your note) after the finding-derived rows; Download System Security Plan prints them as documented gaps with your working total; Download JSON carries the whole register inside the pack's integrity checksum.

Tip: The working total is arithmetic on your own answers, nothing more. It is a draft you review: not an official SPRS score, not calculated on your behalf, not submitted anywhere, and not a certification. Deciding whether a requirement is fully met is your judgment call, and the submission is yours to make.

1. Open the NIST 800-171 requirement register card and expand a family, the same way you would to answer a requirement.
2. Next to the note box on each requirement there is a date field. Pick the date you plan to have that gap closed, then click Not met. The date saves with your answer.
3. The date only applies to a Not met answer. Marking a requirement Met or N/A clears it, because a closed gap has nothing left to plan.
4. The requirement then shows "Target completion: 2026-12-01" under your note, and reads "— overdue" in red once that date has passed.
5. At the top of the card, under your draft working total, a line appears: "Projected at your latest target date (2026-12-01): 68" — what your own total becomes once every gap you have dated is closed by its date. Any dates you have already blown through are counted beside it.
6. Export All findings → Download POA&M. Each Not met requirement now carries your date in the Scheduled Completion Date column, reads In-progress instead of Open, and records "Planned completion: <date>" in the milestones cell. A date that has passed is called out in the comments cell.

Tip: Requirements you have NOT dated still count against you in full, however far out the projection horizon is: it projects the plan you actually stated, never an optimistic guess. A date the system can't read ("soon", "2026-13-40") is discarded rather than stored, because a garbage date in a column an assessor reads is worse than a blank one. Leave every date blank and your POA&M export is exactly what it was before this existed, with one deliberate exception: a requirement where you had already named an owner now reads In-progress rather than Open, which is what having an owner has always meant on the finding-derived rows. Why this matters: DFARS 252.204-7020 gives you a bounded window (commonly 180 days) to close a not-met requirement, and a POA&M with a blank Scheduled Completion Date on every row is the thing an assessor sends back. The projection is still arithmetic on your own answers and your own dates: a draft you review, not a prediction, not an official SPRS score, never submitted anywhere, and not a certification.

1. Set your account default first: Settings → Attestation review cadence. Leave it on the product default (365 days) or pick 30 / 90 / 180 / 365 / 730. Every control area with no cadence of its own inherits this.
2. Open the Security Center → Compliance coverage. Each area you have marked Reviewed or Accept-risk now shows a second pill: "Review due · <date>", computed from the date you marked it plus the cadence in force.
3. Override the cadence for one area from the dropdown next to its mark. Changing the dropdown only changes when the next review is due; it does not re-date your sign-off, because deciding how often to review is not itself a review.
4. Inside 30 days of the due date the pill turns amber. Past the due date it reads "Review overdue" and a "Re-review now" action appears beside it.
5. Click Re-review now when you have actually looked again. That writes a fresh date, which moves the next due date forward by one full cadence. There is no separate reset.
6. Check your exports: the System Security Plan prints "Re-review cadence: every N days — review due <date>" under each area's attestation line, the branded posture report adds the same line to the Attestation column, the POA&M appends it inside the existing Control-Area Attestation cell (no new column), and the JSON evidence pack carries nextReviewDue, reviewStatus, and stale on each area, all inside the pack's integrity checksum.

Tip: Going past a review date is a prompt to look again, nothing more. Your attestation is never deleted, downgraded, or reported as a failed control: the original status, note, and date stay exactly as you made them, and the review state is shown beside them. The cadence is a target you set for yourself: it is not a certification requirement, an audit schedule, or a compliance obligation, and an attestation is your own assertion about your own environment, never a certification or an audit result.

1. Download the JSON evidence pack from All findings → Download JSON.
2. Open the pack and find the integrity block: the algorithm (always sha256), the checksum, and a manifest echoing what the pack covers.
3. To verify: remove the integrity field from the JSON, canonicalize the remainder (recursively sort all object keys, preserve array order), and compute the SHA-256 of that string.
4. Compare your computed hash with the embedded checksum: a match proves the artifact is exactly what the tool emitted; a truncated download or stray edit flips it to fail.
5. Cross-checks: the same checksum is returned in the X-Evidence-Checksum response header on the download, and printed in the branded posture report's footer.

Tip: A content-integrity check over your own output, not a signature, certification, or third-party seal.

1. Open All findings from the sidebar.
2. In the Export row, click Download posture report.
3. The single self-contained page composes your posture score and week-over-week trend, severity distribution and worst product, remediation velocity, compliance control-area coverage, and finding age with the oldest open critical called out.
4. It's print-styled; open it in your browser and use Print → Save as PDF for a clean handoff document.

Tip: The report carries the standing self-assessment disclaimer and the evidence-pack integrity checksum in its footer. A deterministic summary of your own scan, not a certification or audit.

1. Open the Security Center and find the Public trust page & badge card.
2. Optionally enter a Public display name (for example your company name) to head the page.
3. Click Publish trust page. The card flips to Live and mints an unguessable public URL under /trust/.
4. Click Copy next to the Public link to share it, or Open to preview what visitors see.
5. Under Visible cards, tick exactly which summaries are public: Posture score, Severity distribution (counts), Compliance coverage %, and Last-scanned date.

Tip: Only aggregate summary data is ever exposed: no finding details, systems, or remediation steps leave your account. The page is clearly labeled self-attested, not a certification.

1. Publish your trust page first (Public trust page & badge card on the Security Center).
2. In the Embeddable badge section of the card, preview the SVG badge.
3. Click Copy embed to copy the ready-made HTML snippet.
4. Paste the snippet into your site; the badge image is served live from your badge URL and links back to your trust page.

Tip: The badge updates with every scan automatically. If you rotate your trust link, update the embed snippet: the old badge URL stops working with the old token.

1. Open the Public trust page & badge card on the Security Center.
2. To invalidate every previously shared copy while staying published, click Rotate link; a new URL is minted and the old one stops resolving.
3. To take the page down entirely, click Revoke & unpublish; the URL returns 404 immediately and the card flips to Off.
4. Republishing later mints a fresh link; nothing old comes back to life.

Tip: Shares can also carry an expiry: an expired link 404s automatically, exactly like a revoked one.

1. Open Settings from the sidebar and find the Alert notification preferences card.
2. Your account email is shown read-only under “Account email (always included)”; it can never be removed.
3. Under Additional recipients, enter extra addresses one per line (up to 10); they're CC'd on every alert.
4. Pick the Alert severity floor: Critical only (default), or Warnings and above. Info-level findings never trigger emails.
5. Click Save preferences.

Tip: Critical digests are idempotent: you never get the same alert twice for the same finding.

1. Open Settings → Alert notification preferences.
2. Tick “Enable quiet hours (UTC)” and set the start and end hours (0–23). The window spans midnight when start > end: e.g. 22 to 7 covers 10 pm–7 am UTC.
3. Alerts arising inside the window are held, not dropped; the next scan outside the window sends them.
4. The Weekly posture report checkbox controls the weekly recap email (your score and its 7-day change, what opened and closed, your oldest unresolved critical). It's on by default; uncheck it to opt out.
5. Click Save preferences.

1. Open Settings from the sidebar and find the Outbound webhooks section.
2. In the Add endpoint form, enter the Endpoint URL and a Signing secret you generate (you'll verify the X-Hitt-Signature header on your side).
3. Choose the Severity floor for this endpoint: Criticals only, Warnings and above, or All severities.
4. Click Add webhook, then click Test on the new entry to fire a test delivery and confirm your endpoint responds.
5. Verify each delivery on your side: it's signed with HMAC-SHA-256 (X-Hitt-Signature: sha256=…) using your secret.
6. Watch the Recent deliveries history under each endpoint; every attempt is logged with status, time, and attempt number.

Tip: Failed deliveries to still-active findings retry automatically on subsequent scans (up to 4 attempts, with backoff), so a broken endpoint never silently swallows a critical. Deliveries time out after 10 seconds.

1. Open Settings from the sidebar and scroll to the Policy Checker card.
2. Set your policy's Minimum password length and Max password age (NIST favors no forced rotation).
3. Toggle the requirements you enforce: uppercase letters, digits, special characters, MFA for all accounts, and password-reuse prevention.
4. The score and letter grade (A–F) update live as you adjust.
5. Work through the numbered Recommendations list to raise the grade.

1. Open Settings and find the Breached-password check card (below the Policy Checker).
2. Enter the password in the “Password to check” field.
3. Click Check.
4. Read the result: found N times in known breaches (don't use it, and rotate it anywhere it's in use), not found in the corpus, or corpus unreachable, in which case no result is shown rather than a false all-clear.

Tip: The lookup uses k-anonymity: only the first 5 characters of the password's SHA-1 hash ever reach the breach corpus, and the password is never stored or logged.

1. Open Bank connections from the sidebar.
2. Click Connect a bank.
3. Complete the Plaid Link flow to authorize read-only access to the institution.
4. The connection appears under Connected banks with the date it was linked.

Tip: Bank linking is currently in beta on Plaid's sandbox network: you can try the flow safely with Plaid's test credentials, and real institutions arrive when the production switch flips. Billing-integrity checks on your subscriptions run today regardless.

1. Open the Security Center; the AI Analysis panel sits at the top when there's something to say.
2. Read the Overall risk line and summary, then the sections that apply: Connected signals, Pattern interpretation, Predicted emerging risks, Reprioritized by context, and Recommended actions.
3. The “generated N ago” stamp shows when the briefing was produced; every briefing is dated and saved.
4. Expand Previous analysis at the bottom of the panel to compare against the last stored briefing (no new analysis is run) and see how the risk read is trending.

Tip: The briefing is an aid, not the source of truth: your findings, scores, and exports are all deterministic and stand on their own. The latest briefing travels into the JSON evidence pack and posture report with its own self-assessment disclaimer.