Start with the question on your desk.

Who will run your compliance work?

You have a compliance deadline. Decide who will collect evidence, review it, and follow up before you choose a plan.

Your MSP client needs compliance help. Who does the work?

You manage the client's IT. Now their buyer wants security evidence or a SOC 2 report. Before adding compliance to the proposal, agree what the client needs and which work your team, Sythe Labs, and the client will own.

03 / Four chapters

Your customer asked for SOC 2. What do you actually need?

A buyer asks for a SOC 2 report before approving your service. Find out what they'll accept before you commit to an examination or promise a delivery date.

04 / Four chapters

A security questionnaire is holding up your deal

Sales has a spreadsheet full of security questions. Give the buyer answers your team can support, and separate missing evidence from missing controls.

05 / Four chapters

Your next customer has a security review team

The product team wants to buy. Procurement needs to know how you handle their data. Prepare for the larger customer's review without claiming controls you haven't put in place.

06 / Four chapters

You inherited a security program nobody owns

The policies are in a folder and the person who ran the reviews has left. Work out what still happens, what stopped, and who is responsible now.

See how the work gets done

Get compliance evidence reviewed and approved

An auditor asks who reviewed production access this quarter. Use an evidence record to collect the supporting files and get an approver's decision on what they prove.

Get a policy approved, published, and acknowledged

Your access policy needs to reflect a change in how the team works. Review the revised wording, publish the approved version, and assign employees their acknowledgement tasks.

03 / Four chapters

Share security documents through your Trust Portal

A prospective customer asks for your pentest report. Send them to your Trust Portal, where they can read your public security information and request protected documents.

Security

10 illustrated storiesExplore security

Start with your situation

Penetration testing or vulnerability scanning: which do you need?

Use vulnerability scanning for repeatable checks for known weaknesses. Use a scoped penetration test to investigate attack paths and application behavior. You may need both; start with the question the results must answer.

A customer needs a pentest report before they can buy

The buyer asks for an independent test of your application. Agree what needs testing and what report they'll accept before commissioning the work.

03 / Four chapters

You're about to put customer data into a new application

The demo is becoming a live service. Decide which security questions need answers before real customer records reach the application.

04 / Four chapters

New payments, new roles, or a new API change the risk

An old assessment covered the old product. Check whether a new feature changes who can move money or reach customer data, then scope testing around that change.

05 / Four chapters

The scanner found problems. Which ones need action?

A list of severe findings isn't a plan. Check what ran, whether the affected system is exposed, and what still needs investigation before choosing the next action.

06 / Four chapters

You ship every week. Your last pentest is getting old.

A report describes the product that was tested. Compare its scope with today's service before deciding whether to retest fixes, assess new features, or keep scanning known targets.

07 / Four chapters

Do you need EDR for your team's laptops?

Who would notice suspicious activity on a laptop with access to company systems? Decide whether endpoint detection and response fits that risk, and who will act on the information it produces.

08 / Four chapters

You shipped the fix. Did it resolve the pentest finding?

The report is in, and an engineer has shipped a fix. A closed ticket doesn't establish that the reported behavior is gone. Follow the finding into a scoped retest to check whether the issue is resolved.

See how the work gets done

Schedule vulnerability scans and check what actually ran

A scan was scheduled for this month. Did it finish, and which targets did it cover? See how Sythe Labs schedules approved scans and records the outcome of each run.

Send a repository security finding to your issue tracker

An engineer picks up a security ticket and asks, 'Where is this coming from?' Investigate the finding first, then file an issue with the code references and a link saved on the original finding.