First 90 Days Building a Security Program: Week-by-Week Action Plan

If you have a start date set and time before it, do this now:

Review what is publicly available about your new employer's security posture:

• Search Shodan and Censys for the company's IP ranges and domain -- what is internet-exposed before you have even started?
• Check their SSL/TLS configuration via SSL Labs (ssllabs.com/ssltest)
• Search for the company name on HaveIBeenPwned, DeHashed, or IntelX for previously leaked credentials
• Check their DNS configuration: SPF, DKIM, DMARC records via MXToolbox
• Search GitHub for the company's organization -- are there public repositories? Do any contain sensitive information?

This takes 2 hours and gives you your first week's talking points. Nothing says 'I know what I'm doing' like walking in day one with actual findings.

Prepare the questions you will ask in week one:

• Where is customer data stored and what types of data do you process?
• What compliance requirements does the company have or expects to have?
• Have there been any prior security incidents or near-misses?
• Who currently handles security decisions in the absence of this role?
• What external audits, penetration tests, or assessments have been done?
• What is the biggest security concern the CEO or CTO has right now?

Your job in weeks one and two is information collection, not action. Resist the urge to start fixing things.

Priority conversations to have:

Asset inventory sprint (days 3 to 10):

You cannot secure what you do not know exists. Start building an asset inventory:

1. Request admin access to AWS/GCP/Azure and list all resources across all regions
2. Request admin access to your identity provider (Okta, Google Workspace, Azure AD) and export all users and their access
3. Request a list of all SaaS tools the company pays for from Finance and IT
4. Ask engineering for a list of all production services and their dependencies
5. Ask IT for a list of all corporate devices (laptops, servers, network equipment)

Document this in a simple spreadsheet: Asset | Type | Owner | Data Classification | Internet Facing | Has MFA | Last Security Review

What you will find in almost every environment:

• Former employees with active accounts
• SaaS tools no one remembers purchasing with live data in them
• Production services exposed to the internet that engineering thought were internal
• AWS resources in regions nobody is actively using (legacy test environments)
• Service accounts with no owner and excessive permissions

Deliverable at end of week 2: A current-state memo (3-4 pages) describing what you found. Not a plan -- just a factual description of the environment. Share with your manager and the CTO. This demonstrates competence and builds the credibility you will need for week four's conversations.

By week three you have enough context to start fixing things. The goal is not to fix everything -- it is to ship visible wins that demonstrate you can do more than talk.

The highest-ROI quick wins in almost every environment:

1. Deprovision former employee accounts (day 15-16)

You almost certainly found former employees with active accounts in week two. Revoke them. Every one. Walk the engineering lead through your findings: 'We had 7 ex-employees with active AWS access. I've revoked all of them.' This is the fastest way to make the CTO trust you.

2. Enable MFA for everyone without it (day 17-20)

In most companies, MFA is enabled in the IdP but not enforced -- people enrolled are not required to use it. Turn on enforcement. Communicate the change 48 hours in advance. Allow a 2-week grace period for TOTP apps if needed. Expect friction; manage it. The discomfort of MFA enforcement is worth the security.

3. Fix the obvious external exposures (day 18-21)

If Shodan found services that should not be public, work with engineering to remove the public IP or add firewall rules. Pick the two or three most obvious issues and fix them in the first month.

4. Add DMARC (days 14-21 if not present)

If the company does not have DMARC with at least p=quarantine, add it. This is a one-line DNS change that protects the company from email spoofing. Add it at p=none first to monitor for 2 weeks, then move to p=quarantine. Two DNS changes, no engineering required, visible and meaningful.

5. Set up basic security monitoring (week 3-4)

If there is no SIEM or alerting, at minimum set up:

• AWS GuardDuty (5 minutes, $x/month, catches most common cloud threats automatically)
• CloudTrail in all regions with logs shipped to a separate account
• Log alerting for: root account login, new IAM user creation, security group modifications

This is not a comprehensive monitoring program. It is the floor below which you cannot go.

Deliverable at end of week 4: A 'week one to four' summary deck (5-10 slides) for your manager and key stakeholders. Show what you found, what you fixed, and what you deferred. Quantify where possible: '7 accounts deprovisioned, MFA enforced across 100% of users, 3 external exposures remediated, AWS GuardDuty enabled.' This deck sets the tone for your first board or leadership presentation.

With quick wins shipped and credibility established, weeks five through eight are about building the foundational structures that everything else depends on.

Write your three core policies (even if imperfect):

Policies are governance artifacts, not operational documents. A policy does not tell engineers how to do things; it tells them what the company has committed to doing. Three policies cover 80% of compliance requirements:

1. Information Security Policy (ISP): The master policy. Covers scope, roles and responsibilities, the overall security program objectives, and pointers to other documents.
2. Acceptable Use Policy (AUP): What employees can and cannot do with company systems, data, and devices.
3. Incident Response Policy: Who declares an incident, what the escalation path is, and how the company communicates internally and externally.

Do not spend four weeks writing perfect policies. Write a good-enough v1 in two weeks. Get them reviewed and signed by your manager or CEO. That act of approval is what makes them enforceable.

SANS has free policy templates: sans.org/information-security-policy -- use these as starting points. You do not need to write from scratch.

Set up password/secrets management:

If engineers are sharing passwords over Slack or storing them in Notion, fix this now. The investment is small:

• Corporate password manager: 1Password Teams or Bitwarden Business ($4-7/user/month)
• Secrets in code: integrate detect-secrets into your pre-commit hooks across all repos
• Production secrets: AWS Secrets Manager or HashiCorp Vault (start with AWS if you are already on AWS)

Define your asset classification tiers:

Not all data is equal. Create a simple 3-tier classification:

• Tier 1 (Confidential): Customer PII, payment data, credentials, health data, legal documents
• Tier 2 (Internal): Business strategy, financial data, employee information, source code
• Tier 3 (Public): Marketing materials, public documentation, open-source code

Publish this classification as a one-page reference. It becomes the foundation for encryption requirements, access controls, and data retention policies.

Start your vendor inventory:

Map every vendor that has access to Tier 1 or Tier 2 data. This is your TPRM starting point. For each vendor: what data do they access? What is their security certification? What happens if they are breached?

For SOC 2 readiness (if that is on the roadmap), this vendor list becomes your sub-processor register.

At the end of 90 days you need to deliver a security roadmap. Not a completed program -- a credible, prioritized plan.

The structure that works for leadership presentations:

Slide 1: Current state (3 sentences) Where the security program is today. Factual. No blame.

Slide 2: Risk landscape (top 3 risks) The three things most likely to hurt the company. Each risk needs: likelihood, impact, and current mitigation status.

Slide 3: What we have done (90-day wins) Quantified. 'X accounts deprovisioned, MFA enforced, Y exposures remediated, Z policies written.'

Slide 4: The roadmap (next 12 months) Organized by quarter, not by control. Each quarter has a theme: Q3 = 'Foundations' (asset inventory, access reviews, policies), Q4 = 'Detection' (SIEM, monitoring, IR testing), Q1 = 'Assurance' (pentest, SOC 2 readiness), Q2 = 'Certification' (SOC 2 audit period).

Slide 5: What we need (resources) Budget, headcount, tool spend. Frame it in terms of risk reduction per dollar, not tool names.

The 90-day deliverable checklist:

• Asset inventory (cloud, SaaS, devices) documented and owned
• All former employee accounts deprovisioned
• MFA enforced across 100% of corporate accounts
• Information Security Policy, AUP, and IR Policy written and approved
• Password/secrets management deployed
• Basic cloud monitoring enabled (GuardDuty or equivalent)
• DMARC at p=quarantine or p=reject
• Top 3 external exposures from Shodan scan remediated
• Vendor list with security tier assigned for Tier 1 data processors
• 90-day security roadmap presented to leadership

What to defer (do not try to do this in 90 days):

• SOC 2 audit (needs 6-12 month observation period; start the program, do not rush the audit)
• Comprehensive security awareness training (get the policies first)
• Penetration test (until you have fixed the obvious issues; a pentest that just confirms what you already know wastes budget)
• SIEM deployment (basic alerting is enough for now; a full SIEM is a month-long project)
• Zero trust architecture (strategy, not month one implementation)

Mistake 1: Presenting a strategy before you have listened enough

The classic error: arrive week one with a strategy framework you built at your last company and start presenting it before you understand the business. The strategy will be wrong, and the organization will notice. Spend the first two weeks only listening and mapping. Save the strategy for week four.

Mistake 2: Fixing everything instead of fixing what matters

A security audit will reveal 200 things that are wrong. If you try to fix all of them, you will burn out your engineering relationships and yourself in the first 30 days. Pick the 5 highest-impact items and execute them well. Demonstrate prioritization ability -- it is the most important skill a security leader has.

Mistake 3: Treating security as a security problem instead of a business problem

Every control you implement has an operational cost: developer time, employee friction, tool spend. The question is never 'should we have this control?' It is 'does the security benefit justify the operational cost?' If you cannot answer that question, you will lose credibility with engineers and leadership quickly.

Mistake 4: Getting pulled into a major project before you have the basics

Something exciting will be happening when you start -- a major cloud migration, a new product launch, a big enterprise deal. People will want you involved. Participate, but do not let it consume your first 30 days before you have completed the baseline audit. You cannot protect a new environment if you do not understand the old one.

Mistake 5: Not communicating up frequently enough

Your manager and the CEO/CTO do not know what you are doing day-to-day. Send a brief weekly email: three bullet points on what you did, three on what you found, one on what you need. It takes 5 minutes to write and prevents the 'what exactly does the security person do?' conversation that kills credibility.