Detect the finding
Use the existing supported log, website, deep-assessment or configuration workflow to collect the evidence behind the issue.
HOW ASSAYMARK WORKS
From a security finding to a verified remediation decision
AssayMark is designed to answer what is wrong, why it matters, why it received that priority, what should happen next, who should own the work and how the fix can be verified.
Add business context
Present the likely business impact alongside the technical finding so a non-technical decision maker can understand why it matters.
Explain the priority
Expose the real scoring or prioritisation components available for that assessment and explain how the result maps to the displayed priority.
Define the next action
Give actionable findings a recommended owner, target timeframe and remediation guidance rather than leaving them as an unordered alert list.
Track remediation
Move work through Open, In Progress and Verification Pending states, with assignment, due dates and notes where the existing remediation workflow supports them.
Verify the outcome
Re-test findings where the underlying check can safely verify the change. Where it cannot, AssayMark clearly requires manual verification instead of pretending the issue is fixed.
REMEDIATION LOOP
Advice is not the end of the workflow
The remediation lifecycle keeps the finding connected to what happens after the recommendation is made.
Finding detected
Remediation recommended
Assigned / In Progress
Verification Pending
Re-test or manual verification
Resolved — or reopened if the issue returns
Automatic verification is only used where the existing scanner can legitimately re-check the issue. A missing result in a later log sample is not treated as proof of a durable fix.
BUSINESS AND TECHNICAL CONTEXT
One finding, two useful views
Business View focuses on outcome, priority, responsible role, target timeframe and the immediate next action. Technical View focuses on evidence, source, affected asset, available control mappings, implementation steps and verification.
Business View: why it matters
Technical View: evidence and implementation
Why this priority?
Validated framework context where available
No fabricated mappings or hidden score changes
WHAT WE NEVER RECEIVE
What we never receive
When you check a configuration file — a WordPress wp-config.php, an .env file, an Nginx or Apache config — the file is opened and parsed by your own browser. It is never uploaded.
The browser extracts only an allow-list of non-secret settings: whether debug mode is on, whether file editing is disabled, how cookies are configured. Passwords, database credentials, API keys, tokens and salts are never part of that list, so they never leave your machine.
Everything we do receive is then re-validated independently on our side, so a compromised or modified browser can’t produce a false pass.
PRE-LAUNCH REVIEW
See what AssayMark produces on your own systems
Free reviews are available to a small number of UK organisations while AssayMark is pre-launch.