FISMA Services
All U.S. federal agencies continuously work towards improving the security posture of their information systems so that they can remain in compliance with FISMA. New systems must obtain an Authority to Operate (ATO) before they can be brought into production. Due to stipulations set forth in contracts and grants, private companies, universities, and non-profit organizations often need to comply with FISMA as well.
Each FISMA compliance project is unique. These projects tend to be large in scope and full of industry-specific jargon. If you require assistance with a FISMA compliance project, we welcome your inquiry and are happy to propose solutions to fit your unique requirements. Whether you need an entire team to perform the work for you, or just some strategic advice to head you in the right direction, we offer a variety of FISMA advisory services. Each engagement is customized to help you meet your compliance objectives.
WashingtonTech Solutions provides training and resources to assist U.S. federal agencies in complying with the Federal Information Security Management Act of 2002 (FISMA). FISMA is a good law. Before FISMA, U.S. federal agencies were required to comply with very few information security regulations. Prior to FISMA, information security at U.S. federal agencies was a potluck – some things were secure and some weren't…depending on the security safeguards that the agency chose to bring to the table.
The goal of the FISMA Center is to help U.S. federal agencies make a positive difference when it comes to complying with FISMA. The process by which agencies comply with FISMA has come to be known as Assessment and Accreditation (A&A). The annual Federal Computer Security Report Card is based mostly on how well U.S. agencies perform when it comes to A&A. Our goal is to help all agencies improve their grade, and in the process, improve their information security program.
Third-Party Services
TPRM programs must have a clear definition for a third party documented within the TPRM policy. This definition drives the requirements for the third-party inventory at the service level (rather than the third-party entity level). The reason for this is that different services have different risk profiles and one-third party may provide many services to an organization.
​
WTS Risk domains for TPRM:
-
Financial Risk: Decisions that affect the financial sustainability of the vendor.
-
Disaster Recovery/Business Continuity Plan Risk: Affect decisions that satisfy inquiries into the vendor’s due diligence of having a DR and BCP that cover RPO and RTO objectives.
-
Information Security Risk: This domain reviews the robustness of the vendor's information security program that includes policies, processes, standards, and procedures that span the vendor's information security, cybersecurity, and fourth-party engagements.
-
Compliance and Legal Risk: The risk within this domain incorporates the vendor’s failure to identify, manage and monitor legal, regulatory, and statutory mandates on a local, state, and federal level.
-
IT Operations and Compatibility Risk: Ensures the delivery of services is efficient, effective, and timely to support set objectives. Also ensures the specifications and technical requirements of the procured service (hardware, software) is compatible with the organization’s IT business function.
Information security risk responsibility within a Third-Party Risk management program.
-
Develop the risk assessment plan that describes the scope of the assessment.
-
Produce a cyber-risk assessment summary that documents the results of the assessment
-
Provide the results of the cyber-risk assessment result to appropriate parties
-
Keep metrics on the amount of risk within the environment introduced by Third Parties, and provide the metrics to management at a defined frequency
Third-party Risk Assessor during an assessment
-
Prepare for Assessment
-
Develop Assessment Plan
-
Security Control Assessment
-
Security Assessment Summary Report
-
Risk Treatment Plan
-
Risk Registry
​
​
​
​
​
​
​
​
​
​