This article provides general technical and compliance information, not legal advice. Applicable requirements depend on your jurisdiction, industry, the data involved, and your specific use case; confirm your obligations with qualified legal counsel.
Last reviewed: July 2026.
Security and compliance are related but distinct concerns for any custom software system. Security asks whether unauthorized people or systems can access, manipulate, or abuse the application. Compliance asks whether applicable legal, regulatory, and contractual requirements are being met. A system can be reasonably secure while still failing a specific compliance requirement, and the reverse is also true: passing a compliance checklist doesn't guarantee the underlying system is actually secure against real attacks. Security and compliance overlap, but neither proves the other.
Quick Summary
- Security is generally easier and less disruptive to address during architecture and development than after deployment, when changes may affect production data, users, integrations, and operating processes. Secure design reduces the amount of corrective work needed later, but post-launch monitoring and remediation remain necessary regardless.
- Security controls should follow a threat model and the system's actual risk profile, not a fixed checklist applied identically to every project.
- Which laws and standards apply depends on your industry, the data you handle, and your users' location, not on the technology you built with, and not every framework mentioned in this guide (PCI DSS, HIPAA, SOC 2, ISO 27001) applies to every system.
- Authentication proves who a user is; authorization decides what that user is allowed to do. They are different problems and need to be designed and tested separately.
Security Should Be Risk-Based, Not a Fixed Checklist
Not every application needs identical controls. A small internal tool used by five trusted employees and a public-facing platform handling payment data and thousands of external users face genuinely different threat exposure, and applying the same fixed checklist to both wastes effort in one direction and leaves real gaps in the other. Security depth should scale with the sensitivity of the data involved, the size of the exposed attack surface, user count, transaction value, the privilege level of the application, applicable regulatory context, and how reversible a failure would actually be. The rest of this guide describes the controls that matter; how deeply each one needs to be implemented for a specific system is a scoping decision, not a universal answer.
The Main Application Security Risks
The OWASP Top 10 is a widely referenced starting point for thinking about recurring web-application security risks. The categories below summarize several of those risk areas in plain business language rather than reproducing OWASP's exact current taxonomy, which uses more technical naming and is periodically revised:
| Risk category | What it looks like |
|---|---|
| Broken access control | A user can access or modify data or actions they shouldn't be authorized for |
| Injection | Untrusted input reaches a database query, command, or interpreter without proper validation |
| Weak authentication design | Weak credential policies, insecure account-recovery flows, missing multi-factor authentication where the risk actually warrants it, or poor session management |
| Sensitive-data exposure | Personal, financial, confidential, or regulated information becomes accessible to unauthorized users or systems because of weak access control, cryptography, storage configuration, logging, backups, or general data-handling practices |
| Security misconfiguration | Default credentials, unnecessary services exposed, overly permissive settings, or debug modes left enabled in production |
| Vulnerable or outdated components | Third-party libraries and packages with known, unpatched vulnerabilities |
| Logging and monitoring gaps | No reliable way to detect or investigate a security event after the fact |
These categories are widely used in application-security guidance as a structured starting point for reviewing recurring classes of risk, but they should be supplemented by threat modeling and system-specific testing rather than treated as a complete review on their own.
Security Across the Software Development Lifecycle
Treating security as a single pre-launch review misses most of where risk actually gets introduced. A structured approach, sometimes formalized as a secure software development lifecycle and described in frameworks like NIST's Secure Software Development Framework (SP 800-218), spreads security work across every phase instead of concentrating it at the end:
- Planning. Classify the data involved, identify applicable compliance requirements, and establish what level of risk the system actually carries before design decisions get made.
- Design. Define trust boundaries, the access model, and the encryption and key-management approach the system will use, informed by a threat model.
- Development. Follow secure coding practices, keep secrets out of source code, and apply dependency controls as the codebase grows.
- Testing. Combine code review, automated scanning, authorization testing, and dependency scanning, with penetration testing added where the system's risk profile justifies it.
- Deployment. Apply secure configuration, least-privileged access, and monitoring before the system goes live, not as an afterthought once it's already running.
- Operations. Maintain ongoing patching, incident response readiness, periodic access review, and continuous vulnerability management for as long as the system is in use.
When security review is deferred until late in development, design or architecture changes can be more disruptive to make, since code, integrations, data flows, and deployment assumptions may already depend on the original design; see our custom software development process guide for how security review typically fits into a real project schedule.
Threat Modeling Before Choosing Controls
A checklist can't tell you which failure matters most for your specific system; that requires actually mapping the threats first. Threat modeling means identifying the system's assets, its trust boundaries, its entry points, plausible attackers and their motivations, realistic abuse cases, and the failure scenarios that would cause the most damage. Security controls should follow the threat model, not a generic checklist applied without asking what's actually at risk. A system handling payroll data and a system serving a public marketing site face different realistic attackers and different consequences of compromise, and their control sets should reflect that difference rather than converge on the same generic list.
Authentication and Authorization Are Different Problems
Authentication proves who a user is. Authorization decides what that user is allowed to do once identity is established. They're commonly conflated, but they fail independently, a user can be correctly authenticated and still able to perform an action they shouldn't be authorized for, and both need to be designed and tested separately.
On the authentication side: enforce reasonable credential policies, use secure account-recovery flows that can't be trivially abused to take over an account, apply multi-factor authentication where the risk profile of the system actually warrants it, and manage sessions deliberately, session expiration, token revocation on logout, secure cookie attributes, rate limiting, adaptive throttling, suspicious-login detection, or carefully designed lockout controls against credential-stuffing and brute-force attempts, and protection against session fixation and hijacking. A hard lockout policy applied without care can itself become a denial-of-service vector, so weigh that tradeoff deliberately rather than defaulting to the strictest possible setting.
On the authorization side: apply role-based access control where user permissions map cleanly to defined roles, and attribute- or context-based rules where they don't. Enforce object-level authorization on every operation, checking not just whether a user is allowed to perform an action in general, but whether they're allowed to perform it on this specific record. In multi-tenant systems, enforce tenant isolation explicitly rather than relying on client-supplied identifiers. Apply the same discipline to service-to-service permissions between internal components, and review access periodically rather than assuming initial grants remain correct indefinitely.
APIs and Input Are Part of the Attack Surface
Most custom software today is API-driven, and a secure frontend does not compensate for an API that trusts client-supplied identifiers or fails to enforce authorization on every sensitive operation. Every sensitive API operation should enforce appropriate authentication and authorization server-side, rather than trusting client state or frontend controls; not every endpoint needs authentication, some are legitimately public, but public endpoints should still apply relevant abuse controls, validation, and rate limiting where traffic volume, resource cost, or denial-of-service exposure makes them relevant. Add schema and input validation on the server side regardless of what the client already validated, secure error handling that doesn't leak internal details, and, where applicable, versioning and replay protection.
The same discipline applies to input generally: validate on the server, never rely on client-side validation alone, use parameterized queries rather than building queries from raw input, encode output appropriately for where it's rendered, and apply file-upload validation covering content type, size, and actual file content, not just the filename extension.
Encryption, Password Hashing, and Key Management
Encryption is not one control; it's several, protecting against different threats. Data moving between client and server should be encrypted in transit. Sensitive data at rest needs storage- or database-level encryption, and particularly sensitive fields may need field-level encryption on top of that, depending on the threat model. Passwords are a separate case entirely: passwords should be stored using an approved password-hashing function designed specifically for password storage, with appropriate salting and work factors, rather than reversible encryption, since encryption can be reversed with the right key and a proper password-hashing function is deliberately designed not to be. Hashing alone doesn't make a password store safe; weak or unsalted hashing, or a hashing function not designed for passwords, still leaves real risk. None of this matters without disciplined key management: keys need controlled access, secure storage separate from the data they protect, defined lifecycle management, and rotation where policy, cryptoperiod, provider guidance, or a suspected compromise requires it, not rotation on a fixed schedule regardless of context. Backups containing sensitive data need the same encryption treatment as the live system. Encryption is only as strong as the key-management and access-control design around it.
Secrets and Configuration Shouldn't Live in Source Code
API keys, database credentials, cloud tokens, and other secrets don't belong hardcoded in source files or committed to version control. A credential committed to source control should be treated as exposed even if the repository is private, since access history, backups, and forks can all outlive an intended access boundary. Use a dedicated secrets manager or environment-based configuration instead, separate secrets by environment so a staging credential can't reach production, rotate any credential that may have been exposed, and remove default credentials before anything reaches production. Configuration hygiene extends further: disable debug modes in production, apply secure HTTP headers, and grant cloud infrastructure roles the minimum permissions each component actually needs rather than broad administrative access for convenience.
Data Minimization and Privacy by Design
Data you never collect cannot be exposed from your own system, and data you no longer retain cannot be compromised from that storage location later. Before building data collection into a system, ask what's actually necessary for the workflow it supports, why it's being collected, who can access it, where it's stored, how long it needs to be retained, and which third-party processors, if any, receive it. Treating these questions as architecture decisions during design is a practical way to implement privacy-by-design principles, rather than leaving them solely to a post-build compliance review.
Retention needs a realistic lifecycle, not just a policy statement: collection, active use, access, any sharing with third parties, retention, archival, and eventual deletion. Deletion from a primary database doesn't necessarily mean immediate deletion from backups, replicas, or logs, so define what "deleted" actually means for your system rather than assuming a single delete action covers every copy. Many privacy frameworks include principles around purpose limitation, data minimization, and storage limitation along these lines, though the exact legal requirements depend on the applicable jurisdiction and the specific data-processing context.
Logging and Monitoring Are Different Controls
Logging enough to investigate an incident does not mean logging everything. Capture authentication events, access to sensitive data, and administrative actions, while explicitly avoiding passwords, access tokens, and full payment card numbers in logs, and redact other sensitive fields where they'd otherwise appear. Apply the same access controls and retention limits to logs that you'd apply to the underlying data, since a log containing sensitive details is effectively a second copy of that data if it isn't handled carefully.
Logs and monitoring solve different problems. Logs help reconstruct what happened after the fact. Monitoring helps detect that something is happening while it's still in progress, authentication anomalies, unexpected privilege changes, unusual admin actions, abnormal access volume, or error-rate spikes. A system with thorough logs but no active alerting can usually explain an incident after the damage is done; it can't help you catch one early.
Third-Party Dependencies and Supply Chain Risk
Every third-party library, package, or service a custom system depends on is a potential source of vulnerabilities outside your own code. Maintain an actual inventory of what the system depends on, including transitive dependencies pulled in indirectly, use lockfiles to keep versions consistent, and run software composition analysis or equivalent scanning to catch known vulnerabilities before they reach production. A dependency-update policy should prioritize actual risk and exploitability, not blindly install every new version the moment it's released, and abandoned or unmaintained packages deserve periodic review since their vulnerabilities stop getting patched even when yours don't.
Third-Party Vendors and Service Providers
The same supply-chain thinking applies to the services a system depends on, not just the code. Evaluate a third-party service's own security and data-handling practices before integrating with it, understand what data it will actually receive, and confirm what happens to that data if the relationship ends. A weakness in a critical vendor or service can become part of your own risk exposure even when your own application code is secure, especially where that vendor handles sensitive data, identity, infrastructure, or privileged integrations. This also matters for compliance scope, since a vendor handling regulated data on your behalf can extend your own obligations rather than remove them.
Which Compliance Frameworks Actually Apply
What applies depends on your industry, the type of data you handle, and where your users are located, not on the technology stack you built with. It also helps to understand what kind of requirement you're actually looking at, since these terms get used loosely:
| Type | Examples | What it actually is |
|---|---|---|
| Privacy law | GDPR, applicable state privacy laws | Legal obligation, where applicable to your organization and users |
| Sector-specific law | HIPAA | Legal obligation that applies only within defined healthcare data and entity contexts |
| Payment industry standard | PCI DSS | Contractual/industry requirement enforced through the payment card ecosystem, not a government law |
| Assurance framework | SOC 2 | An examination and attestation reporting framework based on the AICPA Trust Services Criteria; the resulting report provides assurance about specified controls for a defined period or point in time. It is not a certification and does not prove the absence of vulnerabilities. |
| Security management standard | ISO/IEC 27001 | A certifiable information security management system (ISMS) standard covering how an organization establishes, operates, monitors, and improves its security governance. Certification does not guarantee that a specific application is free of vulnerabilities. |
A system handling payment data has different obligations than one handling health records, which differs again from a system processing only general business data with no regulated category involved. Systems that store, process, or transmit cardholder data can fall within PCI DSS scope depending on payment flow, architecture, merchant or service-provider role, and how cardholder data is actually handled; using a third-party payment processor can reduce the amount of cardholder-data environment you operate directly, but it doesn't automatically remove every PCI DSS obligation on your side. Similarly, HIPAA applicability depends on whether the organization and the specific data flow fall within the covered-entity or business-associate rules; not every application that happens to contain health-related data is automatically subject to HIPAA. If your system touches healthcare or payment data specifically, see our HIPAA compliance guide and fintech compliance guide for how those requirements typically get addressed; the exact legal obligations still need confirmation with counsel for your specific situation.
Security Testing Before Launch
A vulnerability scanner, a code review, and a penetration test answer different security questions, and none is a universal substitute for the others. Code review and static analysis catch certain classes of coding issues early and cheaply. Dependency and configuration scanning catch known vulnerabilities in what the system depends on and how it's set up. Authorization testing specifically verifies that access controls actually hold up under deliberate misuse, not just normal use. Penetration testing and abuse-case testing simulate a motivated attacker rather than checking against known patterns. The depth of testing that makes sense for a given project should scale with the sensitivity of its data, its privilege level, its external exposure, applicable compliance requirements, and the impact of a compromise, not apply uniformly regardless of what's actually at stake.
Backup, Recovery, and Resilience
Security isn't only about confidentiality; availability and recoverability matter just as much when something does go wrong, including ransomware and infrastructure failure, not just unauthorized access. A backup that has never been restored successfully is not yet a proven recovery control, it's an assumption. Test restores regularly, not just backup creation. Where the risk profile warrants it, keep backups isolated or immutable so a compromise of production systems can't also destroy the recovery path, and define realistic recovery time and recovery point objectives based on what the business actually needs, not a default the infrastructure happened to ship with.
Ongoing Vulnerability and Patch Management
Production software needs a defined process for handling vulnerabilities as they're discovered, not an ad hoc response each time. That means an intake process for new vulnerability reports, a way to classify severity, clear ownership for remediation, and patch timelines that scale with actual risk rather than treating every finding identically. For public-facing systems, a responsible disclosure path gives outside researchers a legitimate way to report issues instead of no path at all, which tends to produce worse outcomes than a clear, monitored channel.
Incident Response Planning
Incident response should be designed before the incident, not improvised during it. A real plan covers identifying what's affected, isolating compromised systems, revoking exposed credentials and tokens, preserving evidence for investigation, determining the actual scope of the incident, restoring service safely rather than rushing back online, notifying anyone required under applicable law or contract, and running a post-incident review that feeds back into the system's controls. Notification requirements and timelines vary by jurisdiction and the type of data involved, so confirm what specifically applies to your situation with legal counsel rather than assuming a single universal standard.
Security Ownership
Security controls without a named owner tend to degrade into assumptions: everyone assumes patching, access review, and backup verification are happening, and nobody is actually confirming it. Assign clear ownership for patching, dependency updates, access reviews, incident response, vulnerability handling, backup verification, and compliance evidence, whether that owner sits internally or with a retained development partner; see our maintenance and support cost guide for how ongoing security work typically fits into a maintenance budget.
Matching Security Depth to Risk
The table below is a practical planning framework, not a legal or industry-standard classification system. Actual security requirements should be based on the system's specific threat model and applicable obligations, not read off a table.
| Risk tier | Typical profile | What that generally means for security depth |
|---|---|---|
| Lower risk | Internal tool, limited sensitive data, a small number of trusted users | Core controls, access control, patching, and basic monitoring, without the full depth needed at higher tiers |
| Moderate risk | External-facing SaaS product handling customer data | Fuller authentication and authorization controls, regular dependency scanning, and a defined incident response process |
| Higher risk | Regulated or transactional platform handling financial, health, or other sensitive data at scale | May warrant threat modeling, independent penetration testing, formal compliance mapping, and dedicated security ownership as a standing responsibility, not a one-time task |
Before Launching Custom Software
Confirm the fundamentals are actually in place
- Data classified, and applicable compliance requirements identified
- A threat model completed for the system's actual risk profile
- Authentication and authorization tested separately, not just authentication alone
- Secrets removed from source code and moved to proper secret management
- Encryption and key handling reviewed, with passwords specifically confirmed as hashed, not encrypted
Confirm the system has actually been tested, not just built
- APIs validated for authorization on every sensitive operation
- Dependencies scanned for known vulnerabilities
- Security testing completed at a depth appropriate to the system's risk tier
- Logging and active monitoring both enabled, not logging alone
Confirm the system can recover, and that someone owns it
- Backups tested with an actual successful restore, not just backup creation
- An incident-response owner defined before launch, not after the first incident
- Data retention and deletion rules implemented across primary storage, backups, and logs
- Third-party vendors reviewed for their own security and data-handling practices
- Production access restricted to what each person and service genuinely needs
Tell us what kind of data your system needs to handle. We'll help you design access controls, encryption, and logging that fit your actual compliance requirements, not a generic checklist.
Talk to Our TeamFrequently Asked Questions
What's the difference between software security and compliance?
Security asks whether the system can actually be attacked successfully. Compliance asks whether specific legal or regulatory requirements are being met. A system can be reasonably secure while still failing a compliance requirement, and the reverse; neither one proves the other.
What is secure software development?
An approach that builds security into every phase of a project, planning, design, development, testing, deployment, and operations, rather than treating it as a single review performed right before launch.
What security controls should custom software include?
At minimum: access control built on least privilege, tested authentication and authorization, encrypted data in transit and at rest, hashed passwords, secrets kept out of source code, dependency scanning, meaningful logging and active monitoring, and a defined incident response plan. Which of these need the deepest investment depends on the system's specific risk profile.
What's the difference between authentication and authorization?
Authentication proves who a user is. Authorization decides what that user is allowed to do once their identity is confirmed. They fail independently and need to be tested separately.
Should passwords be encrypted?
No. Passwords should be stored using an approved password-hashing function designed for password storage, with appropriate salting and work factors, not reversible encryption. Encryption can be reversed with the right key; a proper password-hashing function is deliberately designed not to be, which is what makes it appropriate for password storage.
What is threat modeling?
The practice of identifying a system's assets, trust boundaries, entry points, realistic attackers, and highest-impact failure scenarios before choosing security controls, so those controls address the risks that actually apply to that specific system rather than a generic list.
Does every application need penetration testing?
Not necessarily. A lower-risk internal tool may justify a lighter testing program than a public, regulated platform, while higher-risk systems may warrant deeper testing such as independent penetration testing. The appropriate depth depends on exposure, data sensitivity, privilege, and any contractual or regulatory requirements that apply to the specific system.
How often should software dependencies be updated?
Dependency updates should be prioritized based on known vulnerabilities, exploitability, exposure, vendor support status, compatibility, and the application's overall risk profile, rather than a single universal calendar rule. A software composition analysis or equivalent scanning process helps identify which updates are genuinely urgent versus routine.
Does having a SOC 2 report or ISO 27001 certification mean software is secure?
Not by itself. SOC 2 is an attestation report on specified controls for a defined period, based on the AICPA Trust Services Criteria; ISO/IEC 27001 is a certifiable standard for how an organization manages its information security program. Neither is a technical guarantee that a specific application is free of vulnerabilities. Both demonstrate a level of process maturity and are often required contractually, but they don't replace direct security testing of the actual system.
Does using a payment processor like Stripe remove PCI DSS responsibility?
It can significantly reduce your PCI DSS scope, since less cardholder data touches your own systems, but it doesn't automatically eliminate every obligation. Your specific scope still depends on how payment data flows through your architecture; confirm your actual scope with a qualified assessor rather than assuming a processor handles all of it.
Does custom software need a formal security audit before launch?
It depends on the sensitivity of the data involved, the system's risk tier, and your industry's requirements, but every project benefits from a deliberate security review before launch, with the depth of that review scaled to the system's actual risk rather than treated as optional below some size threshold.
What compliance requirements apply to custom software?
It depends on your industry, the type of data you handle, and where your users are located. Systems handling health data, payment data, or general personal data each carry different specific obligations, and frameworks like SOC 2 or ISO 27001 are separate from legal requirements entirely; confirm what applies to your situation with legal counsel.
How does data minimization help with both security and compliance?
Data you never collect can't be exposed from your own system, and data you no longer retain reduces both your exposure if an incident happens and the compliance burden of justifying what you're storing and why.
Our custom software development team builds access control, encryption, and logging into the architecture from the start, not as something added after launch.